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(57) Abstract: Method and apparatus for trading financial as- 
sets, such as foreign exchange and money market instruments, 
commodities and securities (Figure 2). The invention, which 
may be accessed over an interconnected data communications 
network, such as the Internet, using a standard Web browser, 
as well as a proprietary user interface, receives customer re- 
quirements (205), automatically combines and organizes those 
requirements into a batch of orders according to a set of cus- 
tomer preferences (210), and displays the batch of orders to the 
customer (215), along with indicative or actual price quotes, 
such that the customer may select (220) and process multiple 
orders and multiple requirements in simultaneously. Orders are 
priced and booked automatically. 
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METHOD AND APPARATUS FOR TRADING ASSETS 

Related Applications 

This application is related to and claims priority under 35 U.S.C. §1 19 to 
provisional application No. 60/424,682, filed on November 8, 2002, which is 
incorporated into this application in its entirety by this reference. 

Field Of AH 

The present invention relates generally to financial transaction systems and, 
more specifically, to financial transaction systems where at least a portion of the 
transaction is conducted over an interconnected data communications network, such 
as the Internet. 

Related AH 

In today's global market, money flows freely between investors and 
borrowers, and buyers and sellers, across international borders. Foreign exchange 
("FX") markets, for example, allow market participants to exchange (or "trade") one 
currency for another. In an FX transaction, one counterparty buys a specified 
currency from the other counterparty in exchange for another currency. FX market 
instruments include, for example, spot, forward and swap agreements (defined 
below). 

In another example, money markets allow market participants to borrow and 
lend money. In a money market transaction, one counterparty — the borrower — 
borrows money from the other counterparty — the lender — at a specified rate for a 
specified period of time. Money market instruments include coupon bearing 
instruments, such as certificates of deposit (CDs) and repurchase agreements, discount 
instruments, such as treasury bills, (T-bills) and commercial paper, and derivatives, 
such as forward rate agreements, interest rate futures and interest rate options. 

As investments, most FX instruments and money market are "liquid," meaning 
that they can be bought and sold, and therefore, converted to cash, rapidly. This 
liquidity is the reason many corporate treasurers use these markets to lend or sell 
spare cash to banks as a way of temporarily "parking" the spare cash in a short-term 
low-risk investment vehicle before making a financial decision. The banks use the 
spare cash to make loans to borrowers who need short-term financing. These 
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borrowers may include, for example, other banks, corporations and governments, as 
well as supranational organizations, such as the World Bank. 

Borrowers, lenders, sellers and buyers in these markets conduct their 
transactions through dealers, also called "traders," who borrow and lend money 
5 market instruments or buy and sell FX instruments. The dealers and traders, who are 
referred to as "market-makers" ot "liquidity providers," quote prices that they are 
willing to buy (or borrow) the instruments they deal in, as well as prices they are 
willing to sell (or lend) the instrument. The borrowing or buying price is known as 
the "bid," and the lending or selling price is known as the "offer." The difference 
10 between these two prices is known as the "bid-offer spread," and it is this spread 

which generates profits for market-makers, as they are always buying and borrowing 
slightly more cheaply than they are selling and lending. 

For years, liquidity providers and their customers (the buyers, sellers, lenders 
and borrowers who do business with liquidity providers) would negotiate, execute, 

1 5 confirm and settle transactions, which are often called "deals," from start to finish 
using only manual systems, either by meeting in person (such as at a stock or 
commodity exchange) or by using telephones and fax machines. But as the markets 
have grown, and as trading and dealing activities have expanded to cover 24 hours per 
day, the manual systems have been found to be too slow and inefficient to keep up 

20 with market requirements. Manual systems, for example, do not always provide 

adequate access to the people, prices and transaction records required to accommodate 
the fast pace and higher volumes of today's markets, or to deal with the financial risks 
associated with engaging in these transactions. Manual systems also typically do not 
provide adequate or timely access to current market news, market rates, market 

25 research and other information market participants need to have available and at their 
fingertips while they are making deals. 

Automated online transaction systems for customers and liquidity providers 
have been introduced in an attempt to address some of these problems. But the 
existing automated systems have so far failed to solve many of the most time- 
30 consuming aspects of the older manual systems. For example, existing online 
transaction systems allow a customer, such as an asset manager, to view on an 
electronic blotter quotes provided by counterparty, such as a bank, for a large number 
of outstanding financial requirements. Each financial requirement may comprise, for 
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example, a proposal exchange one currency for another currency on a specified date 
in the future (e.g., an offer to buy a million euros in the equivalent amount of U.S. 
dollars for settlement on January 2, 2004). In some situations, the customer may have 
on his or her blotter and need to deal with, for instance, as many as two-hundred 
5 different quotes for two-hundred different proposed deals. A few of these deals may 
have significant financial value (e.g., a quote responsive to a proposal to trade 50 
million U.S. dollars against euros) and, accordingly, may represent a significant 
financial stake or risk for the customer. A customer will typically want to consider 
each one of these significantly valuable requirements and quotes very carefully and 
1 0 process each one an individual basis. 

In many situations, however, the customer's electronic blotter may also 
contain a large number of quotes for relatively minor deals. These deals may be 
considered relatively minor, for example, because they represent only a small 
financial risk to the customer (e.g., a proposal to buy only $10,000 worth of Japanese 

15 yen). These smaller deals, often referred to as "housekeeping" deals, may arise or 
result, for example, from dividend payments coming due, from hedges previously 
applied that now need adjustment, from fluctuations in asset value due to changing 
exchange rates. Thus, the customer may be faced with having to respond to a large 
number of quotes received for a large number of proposed deals, each deal being of a 

20 relatively small value. Deals of this size typically do not warrant the careful and 

individual consideration and processing required for the higher value deals. However, 
the customer still has to respond to each and every quote, regardless of its value. 
Faced with possibly hundreds of housekeeping deals that need to be processed, 
customers typically just want to get them done quickly, so they can then dedicate their 

25 time and resources to considering and processing the higher value deals. 

In some cases, however, customers may not need to dedicate a lot of time and 
resources to processing or completing high value deals. Such cases might arise, for 
example, when the particular fund to be traded on can only be traded with a single 
bank, when the customer and the counterparty have a general agreement as to the 
30 quality of pricing that the bank will return (e.g. to use a fixed spread off a market 

reference), and so forth. In these cases, the customer cannot, or does not need to trade 
in competition, and, therefore, just wants to be able to quickly and efficiently get the 
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deals done and out of the way so he can move on to considering deals that do warrant 
detailed consideration. 

One disadvantage associated with conventional automated online transaction 
systems, however, is that they require that the customer separately process each and 
5 every deal (e.g., by accepting or denying the quotes). When there are a large number 
of relatively insignificant deals on the blotter, this process can be very time 
consuming. Responding to each deal can also be very expensive relative to the value 
of those deals to the customer because the customer typically has to pay a separate 
brokerage fee on each separately-processed deal. 

10 Another disadvantage associated with existing automated online transaction 

systems is that each deal must be separately priced or confirmed by a sales person or 
other representative at the counterparty (typically a bank), which significantly 
increases the time required to fully process a large collection of small deals. 

Accordingly, there is need for an automated online transaction system that 
1 5 allows customers to collectively process a number (i.e., a "batch") of deals quickly 
and efficiently with a minimum number of instructions, keystrokes or mouse clicks. 
There is a further need for such systems to automatically arrange and compute "netted 
values" for multiple deals. "Netting" transactions means combining multiple 
payments arising from different transactions into a single, equivalent payment, 
20 thereby reducing the number of payments between the parties and, in most cases, 

reducing the overall transaction cost associated with completing multiple transactions. 
These systems would be even more useful if they were capable of collectively 
processing the batch according to a set of preferences associated with the customer, 
counterparty bank, or both of them, and also took into account the customer's credit 
25 profile and governmental or industry regulations and restrictions. These systems 
would be even more useful if they included components and/or processors for 
quoting, confirming and settling batches of deals automatically, with little or no 
human intervention required at the counterparty bank or provider. 

Summary of the Invention 

30 The present invention addresses the above described and other disadvantages 

associated with existing automated online transaction systems by providing systems 
and methods for automatically processing (e.g., submitting, quoting, accepting, 



-4- 



WO 2004/044811 



PCT/US2003/035486 



booking, confirming and settling) multiple deals in a batched manner. The invention 
further provides that the batches may be processed according to a set of default or 
specified preferences associated with the customer, the counterparty, governmental or 
industry standards and regulations, or all of the above. 

5 In general, the present invention comprises a method of trading assets 

comprising the steps of: (1) establishing a communications channel with a customer; 
(2) receiving a set of requirements from the customer via the communications 
channel; (3) arranging the set of requirements to fdrm a batch of orders, each order in 
the batch comprising a subset of the set of requirements; (4) automatically providing a 

10 quote for at least one order in the batch, the quote comprising a price for executing a 
group of trades, each trade in the group corresponding to a requirement in the order; 
(5) presenting the quote to the customer via the communications channel; (6) 
receiving an acceptance for the quote from the customer via the communications 
channel; and (7) responsive to the acceptance, booking the group of trades. 

1 5 When the set of requirements comprises at least two requirements having in 

common between them a particular currency pair, bank account or value date, the 
arranging step may further include assigning these requirements to the same order in 
the batch of orders. Preferably, a netted value for the two requirements is then 
computed and displayed to the customer for approval or rejection. These 

20 requirements may or may not have the same dealt currency (defined below). The 
mechanics of computing netted values for requirements are described in the detailed 
description section below in conjunction with the detailed description of an exemplary 
batch management server component of one embodiment of the present invention. 

The subset of requirements may include, for example, a proposal to exchange 
25 one currency for another currency, a proposal to lend or borrow a sum of money, a 
proposal to buy or sell a commodity or a proposal to buy or sell a security. The group 
of trades may comprise any number of trades, including just one trade, as required to 
satisfy all of the requirements in the order (or orders) automatically quoted. In some 
embodiments of the invention, the method further includes the steps of generating and 
30 displaying one or more indicative prices for executing one or more trades in the group 
of trades. An indicative price engine may be used to generate the indicative prices. 
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As stated above, the invention may be applied in a variety of different asset 
trading contexts, including but not limited to trading foreign exchange and money 
market assets, commodities and securities. In the context of trading foreign exchange 
assets, a "requirement" is an individual foreign exchange proposal (e.g., "I would like 
5 to buy 1 million euros in U.S. dollars for settlement on January 2, 2004, in bank 
account number 12345"), An "order" comprises a set of one or more requirements 
sent to a counterparty (usually a bank) to be collectively priced or executed as a unit. 
In other words, when the bank provides a quote on the order, the bank is essentially 
offering to provide the requirements at the stated price, so long as the customer agrees 

1 0 to trade on all of the requirements in the order. Thus, after receiving a quote on an 
order, the customer cannot then choose to trade on only some of the requirements in 
the order. The customer may trade on all of the requirements in the order to get the 
quoted price, or none of them. A ''batch" is a set of one or more orders, which can be 
collectively priced and/or executed substantially simultaneously using a minimum of 

15 instructions, keystrokes or mouse clicks. Once the customer has received price quotes 
on a batch of orders, the customer may elect to trade on one order, more than one 
order, all of them or none of them. 

In preferred embodiments, the present invention further comprises the step of 
receiving from the customer, via the communications channel, a request to provide the 

20 quote, also known as a "request for quote" or "RFQ." The method may further 
include the steps of executing the group of trades and sending a notice to the 
customer, via the communications channel, indicating that the group of trades has 
been executed. Trade details associated with the group of trades may then be stored 
in a transaction database configured to hold such information. Preferably, although 

25 not necessarily, the method includes the subsequent steps of matching, confirming, 
settling, outsourcing and/or amending one or more trades in the group of trades based 
on corresponding sets of trade details stored in this transaction database. 

Preferred embodiments of the invention also include arranging the set of 
requirements according to a default set of preferences associated with the customer. 
30 The invention also allows the user to override the default set of preferences and create 
one or more arbitrary orders from the set of requirements (i.e., the customer manually 
instructs the system to combine into a single order requirements that would not be 
combined if the default set of preferences were used). The customer may also instruct 
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the system to delete requirements from an order, move a requirement from one OTder 
to another, or the combine two orders in the batch to form new order. Accordingly, 
the method may further include receiving an instruction from the customer, via the 
communications channel, to use or modify the default set of preferences, or to modify 
5 the default arrangement of requirements in any or all orders. The set of preferences 
may include, for example, a maximum or a minimum value for an individual order, a 
preferred set of accounts or counterparty banks to use, a preferred set of currencies of 
settlement dates, etc. 

The invention may also be used to collectively trade requirements involving 
10 assets from different classes. For instance, a customer may be interested in buying a 
security sold on a foreign securities market. But he must first convert his domestic 
currency (e.g., U.S. dollars) into the currency accepted by that foreign market (e.g., 
yen). Thus, the set of requirements may include both a proposal to buy or sell a 
security (a securities asset class) and a proposal to exchange one currency for another 
15 currency (a foreign exchange asset class). In this case, the arranging step may include 
assigning the securities requirement and the foreign exchange requirement to the same 
order and computing a netted value for the two requirements, even though they are not 
in the same asset class. 

In addition to automatically generating a quote for an order in the batch, or as 
20 an alternative to it, the invention may be used to automatically generate quotes for 
every order, in the batch, resulting in a collection of quotes for a collection of orders. 
Thus, according to principles of the invention, a customer may elect to collectively 
process all of the requirements in one order in the batch, all of the requirements in 
multiple orders in the batch, or all of the requirements in all of the orders in the batch. 
25 Collectively processing requirements means, for example, requesting indicative prices 
or quotes for all of the requirements in one or more orders, requesting that all of the 
requirements in one or more orders be sent to a preferred counterparty, requesting that 
all of the requirements in one or more orders be sent to a plurality of preferred 
counterparties, instructing the system to accept the prices quoted on all of the 
30 requirements in one or more orders, etc. 

In some cases, the customer may instruct the system, through a series of 
instructions, keystrokes or mouse clicks on a user input screen, for example, to send 
one or more orders to a counterparty along with a signal (flag or other indicator) to 
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indicate to the counterparty that the one or more orders being sent contain one or more 
details associated with a prior transaction between the customer and the counterparty. 
The prior transaction may have been partially or fully executed, for instance, in a 
face-to-face meeting between the customer and the counterparty, on or over an 
5 automated online transaction system, or through a telephone or facsimile connection. 
Typically, although not necessarily, the customer instructs the system to send the 
order along with this signal or flag when it is necessaiy or desirable for the 
counterparty to provide a missing or additional term to complete the quote prior to 
booking and/or execution of a trade. 

1 0 For foreign exchange orders, for example, a customer and provider may have 

already traded, in a prior transaction conducted over the telephone, the netted spot 
position of all of the requirements in an order of the prior transaction. The netted spot 
position refers to the net amount of currency traded by the parties, based on a 
computed netted value for all of the requirements in the order of the prior transaction. 

1 5 Thus, the signal, flag or other indicator would be used, for example, to indicate to the 
provider that the current order contains the amounts for each value date for each 
requirement in the order of the prior transaction. In another case, the customer may 
set the flag (or cause the flag to be set) to signal the provider that the current order 
contains other details, needed to complete the order of the prior transaction, such as 

20 account numbers and value dates for each requirement in the order of the prior 

transaction. Typically, the provider will then provide prices for any non-spot value 
dates to complete the quote. 

In accordance with some embodiments, the 'invention also includes the steps of 
establishing a second communications channel with a counterparty, presenting the 

25 order to the counterparty via the second communications channel and receiving the 
quote from the counterparty, via the second communications channel. In this 
embodiment, the method also may optionally include the steps of transmitting the 
acceptance to the counterparty via the second communications channel, receiving a 
confirmation from the counterparty responsive to the acceptance and sending the 

30 confirmation to the customer via the first communications channel. Another option 
includes the step of sending a notice to the counterparty, via the second 
communications channel, indicating that the group of trades has been booked. 



-8- 



WO 2004/044811 



PCTAJS2003/035486 



In another aspect of the present invention, there is provided another method of 
trading assets, comprising: (1) establishing a communications channel with a 
customer; (2) receiving a set of requirements from the customer via the 
communications channel; (3) arranging the set of requirements to form a batch of 

•5 orders, each order in the batch comprising a subset of requirements in the set of 

requirements; (4) receiving from the customer a request to book an order in the batch; 
(5) booking the group of trades in response to the request, each trade in the group 
corresponding to a requirement in the order, and (6) transmitting to the customer a 
booking detail associated with the group of trades. The booking detail may comprise 

10 for example, execution, pricing, account or value date information, which may be 
transmitted to the customer via the communications channel established with the 

i. 

customer or through some other means, such as by telephone, facsimile or electronic 
. mail. 

This aspect of the invention does not necessarily include the steps of 
1 5 requesting or providing pricing information, such as indicative prices or quotes, to the 
customer before the group of trades is booked. The trades may be automatically 
booked or executed, preferably in accordance with a set of trading rules or customer 
preferences, in response to the customer providing the set of requirements. Such 
trades may be booked or executed by the bank, based on an understanding with the 
20 customer that the provider will give the customer the best price available. The 

method may further include the step^s of sending a notice to the customer indicating 
that the group of trades has been executed and providing execution details to the 
customer. Preferably, execution details associated with the group of trades are stored 
in a database, where they may be retrieved for further processing, such as matching 
25 and confirming the details of trades booked on behalf of the customer with the details 
of trades booked on behalf of the counterparty. 

In still another aspect of the invention, there is provided a method of 
interacting with a computer system so as to trade assets, comprising: (1) launching an 
order management system that includes a command to establish a communications 
30 channel with the computer system; (2) providing a set of requirements to the computer 
system via the order management system; (3) invoking a command in the order 
management system so as to cause the computer system to generate a batch of orders, 
each order in the batch comprising a subset of requirements from the set of 
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requirements; (4) selecting a control in the order management system so as to cause 
the computer system to provide a quote for collectively executing a group of trades to 
fulfill every requirement in at least one order in the batch; and (5) issuing an 
instruction, via the order management system, to accept the quote. In a preferred 
5 embodiment, the method may further comprise the steps of: (6) executing a command 
in the order management system to provide a set of preferences associated with the 
group of trades, (7) selecting another control (such as a button or check box in a 
graphical user interface) configured to cause the computer system to send the order to 
a counterparty. 

10 According to another aspect of the present invention, an asset trading system is 

provided, which comprises: (1) a communications channel for receiving a set of 
requirements from a customer; (2) a batch manager configured to arrange the set of 
requirements into a batch of orders, each order in the batch comprising a subset of 
requirements from the set of requirements; (3) a trading server configured to provide a 

1 5 quote for an order in the batch, the quote comprising a price for executing a group of 
trades, each trade in the group corresponding to a requirement in the order; and (4) a 
user interface configured to present the quote to the customer, via the communications 
channel, and to receive an acceptance for the quote from the customer via the 
communications channel. The trading server is further configured to book the group 

20 of trades in response to the acceptance received by the user interface. 

In some embodiments, the batch manager is configured to arrange the set of 
requirements according to a set of preferences. The user interface is further 
configured, in preferred embodiments, to receive from the customer, via the 
communications channel, a request to provide the quote, to send a notice to the 

25 customer, via the communications channel, indicating that the group of trades has 
been executed, and to receive an instruction from the customer, via the 
communications channel, to modify the set of preferences or the default arrangement 
of requirements in one or more orders. The user interface may also be configured to 
receive from the customer a request to send the order to a particular counterparty or 

30 group of counterparties. The set of preferences may be stored, according to principles 
of the present invention, in an optional administrative server configured for this 
purpose. Moreover, the trading server may be further configured to execute the group 
of trades. 
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In practice, a system configured to operate according the present invention 
also includes netting functionality, so that when the set of requirements comprises at 
least two requirements having in common between them a particular currency pair, a 
particular account or a particular value date, the batch manager will assign the at least 
5 two requirements to the same order and compute a netted value for those two 
requirements. Such netting functionality may be implemented in cases where the 
requirements do not have the same dealt currency, as well as cases where they do 
have the same dealt currency. Further still, the batch manager also may be 
configured, in preferred embodiments, to combine and compute the netted value of 
10 requirements having mixed asset classes (e.g., where one requirement calls for a 
currency exchange and another requirement calls for buying or selling a security). 

The system optionally includes an indicative price engine configured to 
generate indicative prices for executing the group of trades, so that the customer may 
obtain useful pricing information about state of the market for the submitted 
15 requirements prior to requesting and/or obtaining actual quotes from counterparties. 
The indicative price engine may or may not be coupled directly to the batch manager, 
user interface or trading server. 

As stated above with respect to the inventive methods of the present invention, 
the customer may elect to collectively process a single order in the batch, multiple 

20 orders in the batch, or all orders in the batch. Therefore, the batch manager in a 
system configured to operate in accordance with the present invention is further 
configured to produce a collection of quotes for a batch, one quote for every order in 
the batch. In addition, the user interface may be configured to present the collection 
of quotes to the customer via the communications channel, and to receive from the 

25 customer, via the communications channel, an instruction to accept the collection of 
quotes. With this functionality, the customer may quickly and efficiently instruct the 
system to quote, book and/or execute an entire batch of requirements. 

The system optionally includes a second communications channel, coupled to 
the trading server, configured to convey the order from the trading server to a 
30 counterparty, to convey the quote from the counterparty to the trading server, and to 
convey the acceptance from the trading server to the counterparty. The second 
communications channel may also provide the conduit for conveying a confirmation 
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responsive to the acceptance from the counterparty to the trading server, which is 
typically sent to the customer through the user interface. 

In each of the embodiments of the present invention described herein, the 
communications channel may comprise, for example, an Internet connection, a wide 
5 area network connection, a local area network connection, a telephone connection, or 
some combination of one or all of the above-listed types of connections. 

In some embodiments of the present invention, the system may further include 
an order management system configured to receive input directly from the customer 
under the control of the user interface server, as well as a straight-though processing 

10 ("STP") adapter. An STP adapter typically comprises one or more pieces of 

hardware, software, or both, which is configured to convert requirements from one 
standard or proprietary format to another in order to provide seamless, automated, 
electronic transfer of trade information to all parties involved in the trading cycle. On 
the counterparty side, a system configured to operate according the principles of the 

1 5 present invention also may include a counterparty trade management system 

configured to receive input directly from the counterparty under the control of the 
trading server. The trade management system also may include and/or be coupled to a 
rate engine configured to generate the actual price for each requirement in the set of 
requirements. 

20 Finally, in preferred embodiments of this aspect of the invention, the system 

includes a security server configured according to methods well-known in the industry 
to prevent unauthorized access to the user interface server, batch manager server and 
trading server. Typically, the security server will be coupled to a security database 
comprising security-related data associated with customers, banks, brokers and other 

25 providers. 

In still another aspect of the present invention, there is provided a user 
interface for trading assets on a computer system. The user interface is invocable by 
an order management system, and comprises two display screens, which may or may 
not be visible simultaneously. The first display screen is configured to receive input 
30 including a set of requirements, from a customer. The second display screen, on the 
other hand, is configured to display, responsive to the input received from the first 
display screen, a batch of orders, each order in the batch comprising a subset of 
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requirements from the set of requirements, a quote for each order in the batch, each 
quote comprising a price for executing a group of trades, each trade in the group 
corresponding to a requirement in the subset of requirements, and a user-activatible 
control configured to cause the computer system to collectively execute the group of 
5 trades. The orders, as displayed by the user interface in this aspect of the invention, 
may comprise all of the requirements in the set of requirements having a particular 
currency pair, all of the requirements in the set of requirements associated with a 
particular account, all of the requirements in the set of requirements having a 
particular value date, or some combination of each of the above. 

10 Thus, it is a feature of the present invention that it allows customers to process 

multiple requirements in a batched manner so that die customer may dispose .of 
multiple requirements as quickly and efficiently as possible. The requirements may 
represent large value deals, small value deals, or any size deal in between. It is 
another feature that it provides a user interface that invokes such processing with a 

1 5 : minimal number of required instructions, keystrokes and mouse clicks from the 

customer. It is a further feature that, once the batch-mode processing is invoked by 
the customer, the system may automatically provide indicative prices, quotes, trade 
bookings, trade executions, or some combination thereof with little or no human 
intervention on the part of the transaction counterparty. 

20 Together, all of these features provide significant advantages over existing 

automated online transaction systems in terms of time, effort and costs associated with 
processing trading requirements in a variety of different contexts. 

Brief Description of the Drawings 

The present invention and various aspects, features and advantages thereof are 
25 explained in detail below with reference to exemplary, and therefore non-limiting 
embodiments and with the aid of the drawings, which constitute a part of this 
specification and include exemplary embodiments of some of the various forms of the 
invention. In these drawings: 

FIG. 1 shows a high-level block diagram of an asset trading system configured 
30 to operate in accordance with the present invention. 

FIGS. 2 and 3 together contain a high-level flow diagram illustrating the steps 
that might be performed by an asset trading system, a computer system, a processor or 
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combination of processors configured to operate in accordance with an embodiment . 
of the present invention. 

FIG. 4 illustrates an example of a user input screen that may be used to copy, 
paste and import trading requirements into an asset trading system configured to 
5 operate in accordance with principles of the present invention. 

FIGS. 5 and 9 show examples of display screens that may be used, in 
accordance with features of the present invention, to present a batch of orders and 
requirements to the customer, along with indicative quotes, before they are submitted 
to a counterparty, such as a bank. In accordance with an embodiment of the present 
10 invention, the display screens of FIG. 5 and 9 contain "allocation views" of the 
requirements, which show all of the requirements that make up the batch of orders. 

FIGS. 6 and 10 also show examples of display screens that may be used, in 
accordance with features of the present invention, to present a batch of orders and 
requirements to the customer, along with indicative quotes, before they are submitted 
15 to a counterparty, such as a bank. According to embodiments of the present 

invention, however, the display screens of FIGS. 6 and 10 contain "summary views" 
of the trading requirements, which view constitutes an alternative to the allocation 
view depicted in FIGS. 5 and 9. 

FIGS. 7 and 1 1 show allocation views of the requirements and price quotes for 
20 a batch of orders and quotes as they might be returned from bank. 

FIGS. 8 and 12 show summary views of the requirements and price quotes 
returned after the batch has been submitted to a bank. 

In FIGS. 4 through 8, the orders are "netted" across requirements that have the 
same currency pair and the same dealt currencies. In FIGS. 9 through 12, however, 
25 the orders are "netted" across requirements that have the same currency pair and 
different dealt currencies. 

Detailed Description of the Preferred Embodiments 

Although the detailed description of preferred embodiments provided herein 
refers primarily to foreign exchange (FX) deals, these references are only meant to 
30 illustrate in clearer detail how the invention may be applied in that particular context, 
not to serve as a limitation on the applicability of the invention in other contexts. 
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Therefore, such references should not be construed to mean that other kinds of 
financial transactions, such as money market, commodity and security transactions, 
are outside the scope of the claimed invention. 

Definition of Terms 

5 As used in this description, except to the extent that the context indicates 

otherwise, the following terms may be understood with reference to the definitions 
provided below. 

FX Terms 

A "foreign exchange" or *TX" transaction (or "deal") is a contract to exchange 
1 0 one currency for another at an agreed rate on a specified delivery date, also called a 
"value date." 

A "value date" or "settlement date" is the date on which the exchange of 
currencies will take place. 

The terms "FX spot deal," "spot trade" and "spot agreement" refer to a 
1 5 transaction or agreement to exchange a single foreign currency for another (i.e., to 
buy X units of one currency, sell Y units of another currency) on the FX spot date. 

The 'TX spot date" is usually two working days from the date the agreement is 
made and is the most liquid (i.e. cheapest) date to buy or sell currency on a given ' 
trading date. 

20 The term "swap" or "swap agreement" refers to a deal involving the 

simultaneous purchase and sale, or sale and purchase, of a specified amount of one 
currency against another for two different value dates. Although a swap is a single 
transaction with a single counterparty, the transaction has two value dates (or 'legs") 
when the exchanges of funds occur. 

25 A "spot rate" is a rate (expressed as combination of a bid (buy) price and an 

offer (sell) price) at which a market maker will buy and sell the base currency against 
another currency. 

The term "All-in rate" typically refers, in the context of outrights, to the 
overall rate at which the exchange will occur. The all-in rate is calculated by adding 
30 the spot rate and the FX points (the price adjustment). 
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A "single spot portfolio" (SSP) is an FX deal involving one or more legs in a 
single currency pair on any combination of value dates. The dealt currency should be 
the same for all legs. SSP price quotes typically have four components: a spot rate, 
the FX points for each of the non-spot value dates, and the all-in rates for each of the 
5 non-spot value dates . 

A "multiple spot portfolio" or "multi-spot portfolio" (MSP) is an FX deal 
involving one or more legs in multiple currency pairs on any combination of value 
dates. The dealt currency is not the same for all legs. 

Parties 

10 The term "Provider" is typically a shorthand reference to a "Liquidity 

Provider." A "Liquidity Provider" is typically a financial institution, such as a bank, 
that serves as a market maker in a trading system. Liquidity Providers quote prices in 
response to requests from "customers." 

The term "bank," as used herein, is typically used interchangeably with- 
15 "Provider." 

The term "dealer" or "trader" typically refers to an employee of the bank or 
Liquidity Provider who monitors the system from the Provider side and responds to 
customers' requests for price quotes. 

The term "customer" typically refers to a user of the system who is not a bank, 
20 provider, dealer or trader. Customers initiate the dealing process by asking one or 
more Providers for a price on a particular FX instrument, such as a swap, forward or 
spot transaction. While "customer" is typically essentially interchangeable with 
"user," in some cases, depending on the context, a "customer" may also refer to an 
aggregation of users, as, for example, in a company. 

25 Miscellaneous Concepts 

The term "Straight-through-Processing" refers to the end-to-end automation of 
the trading process from order to settlement. It involves the seamless, automated, 
electronic transfer of trade information to all parties involved in the trading cycle as 
early as possible. 

30 The term "dealt currency" is a foreign exchange term that refers to the fixed 

currency in a foreign exchange proposal or quote. For example, if a foreign exchange 
market participant proposes or quotes a deal to exchange 1 million euros for the 
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equivalent amount of U.S. dollars, then the deal entails trading a fixed amount of 
euros against a variable amount of U.S. dollars. The amount of U.S. dollars depends 
on the exchange rate. Thus, the dealt currency in this transaction, also referred to as 
the "base currency," is euros. The U.S. dollar, on the other hand, is referred to as the 
5 "counter currency." 

The terms "netting," "netted spot position" and "computing a netted value" 
refer to the process of combining multiple payments arising from different 
transactions into a single, equivalent payment. Netting multiple transactions, 
requirements or deals usually simplifies the settlement process and reduces 
10 transaction costs. 

Acronyms 

API - Application Programmer Interface. Used colloquially without expansion 
to denote a computer-to-computer interface. 

OMS - Order Management System. An Order Management System is used by 
15 a Customer to maintain a record of which FX that deals need to be executed in the 
% market, who should execute them, etc. Once a deal is executed, the OMS is typically 
updated with the execution rate for each deal. 

SSP - Single Spot Portfolio. A foreign exchange transaction or "deal" 
involving multiple value dates for a single currency pair. The Provider quotes a single 
20 spot rate (hence the name) together with FX points for each value date. 

MSP - Multiple Spot Portfolio. A foreign exchange transaction or "deal" 
involving multiple value dates for multiple currency pairs. 

RFQ - Request For Quote. A trading protocol whereby the customer initiates a 
trade by asking for a price on a particular currency pair, value date, and amount. The 
25 bank responds by sending a price (i.e., a quote) back to the customer. In order to 

accept the price, the customer typically sends the provider an acceptance or an "Offer 
to Deal." 

USD - United States Dollars. 

GBP - United Kingdom Sterling 

30 JPY - Japanese Yen 

CHF - Swiss Franc 
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EUR - European Euro 

CAD - Canadian Dollars 

NOK - Norwegian Kroner 

High-Level Architecture Description 
5 FIG. 1 shows a high-level block diagram of a asset trading system configured 

to operate in accordance with the present invention. As shown in FIG. 1, a computer 
system 100, according to the principles of the present invention, comprises a user 
interface server 1 10, a batch management server 1 1 5, a trading server 120, an 
indicative price engine 125, an admin server 130 and a transaction database 135. As 
1 0. shown in FIG. 1 , and described in more detail below, an asset trading system 

configured to operate in accordance with the present invention may also include a 
security server 160 and a security database 165, as well as a customer order 
management system 140, a straight-through-processing (STP) adapter 145, a rate 
engine 150 and a counterparty trade management system 155. 

15 Customer order management system 140 typically comprises a standard or 

proprietary program or processor configured to accept customer input, such as a list of 
foreign exchange requirements. Customer order management system 140 also may 
comprise, for example, an ordinary spreadsheet suitable for importing and exporting 
requirements by means of simple cutting and pasting commands well known to users 

20 of modem computer systems. Customer input may be provided on customer order 
management system 140 via user input screens, fields, buttons and controls 
manipulated by keyboard keystrokes, mice and other computer input devices. STP 
adapter 145 serves as a translator of sorts, as it is configured to convert requirements 
and messages from one format to another as those requirements and messages are 

25 moved from the customer order management system to the user interface server, and 
vice versa. 

User interface server 1 10 is configured to establish an online connection (e.g., 
an Internet connection) with one or more customer-side applications, such as 
customer order management system 140 and STP adapter 145, via link 101. User 
30 interface 1 10 is also configured by well-known methods to generate and transmit 

input and output screen images (e.g., Hyper-Text Markup Language web pages) to the 
customer-side applications via link 101. User interface server 110 also receives input 
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and instructions (typically in the form of mouse clicks and key strokes) from the 
customer, and passes such input and instructions to the appropriate system component 
(e.g, the batch management server 1 15, trading server 120 or transaction database 
135) for further processing. 

5 Batch management server 115 combines, collates and/or arranges requirements 

submitted by the customer via online connection 101 and user interface server 1 10 
into a batch of one or more orders, each order containing one or more of the 
requirements. Preferably, although not necessarily, batch management server 115 
carries out these operations according to a set of default preferences or profiles stored 
10 in admin server 13 0, or otherwise provided by the customer along wi{h the 
requirements. In a preferred embodiment, batch management server 115 also 
computes netted values for requirements having in common between them the same 
currency pairs, the same accounts and/or the same value dates. 

The mechanics of the netting process are typically defined by a netting 
15 agreement between the customer and counterparty. A typical process is for the two 
parties to review cash flows scheduled for the same bank account on the same value 
date and agree to exchange only a net payment. Note that the underlying deals that 
generated the scheduled payments may have been executed on different dates. Once 
the net payment amounts have been agreed, any new trades must be settled separately, 
20 or the initial net payment schedule must be undone. If there are several such trades, 
they can likewise be netted together into a single payment, but the original netted 
payment remains unchanged. 

Table 1 below illustrates by example one of the advantages of netting 
payments for trade requirements having the same currency pair before executing and 
25 booking the trades. 

Table 1 ; Netting Trades with Same Currency Pair 

Requirements: — 
ACCT1 needs to buy 100,000 EUR vs USD (dealt currency = EUR) 
ACCT2 needs to sell 200,000 EUR vs USD (dealt currency = EUR) 

Current Market Rate: 

1.1766-1.1769 (bank buys EURs at $1.1766/EUR and sells EUR at $1.1769/EUR) 
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Without netting: — 
Customer pays 100,000*1.1769 = $117,690 to buy 100,000 EUR for ACCT1 
Customer receives 200,000*1 .1 766 = $235,320 to sell 200,000 EUR for ACCT2 
Result: Customer receives $1 17,630 ($235,320 - $1 17690) in exchange for 100,000 EUR 

With netting: 

Net requirement is to sell 100,000 EUR vs USD 

Result: Customer receives $117,660 ($100,000*1.1766) in exchange for 100,000 EUR 



As shown in Table 1, tlie customer saves $30 ($1 17,660 - $117,630) by trading 
the two requirements on a netted basis instead of trading them separately. 

5 Table 1, above, shows the results of netting two requirements that specify the 

same dealt currency (in this case, euros). Requirements having the same currency 
pair, however, may be netted even if they do not have the same dealt currency. This 
process is called "infra-currency pair netting." Table 2 below illustrates by example 
the advantage of intra-currency pair netting. 

1 0 Table 2 : Netting Trades with Different Dealt Currencies 

Requirements: ™ — ~~= — 

ACCT1 needs to buy 100,000 EUR vs USD (dealt currency = EUR) 
ACCT2 needs to buy 200,000 USD vs EUR (dealt currency = USD) 

Current Market Rate; 

1.1766-1.1769 (bank buys EURs at $1.1766/EUR and sells EUR at $1 .1769/EUR) 
Without netting: 

Customer pays 100,000*1.1769 = $117,690 to buy 100,000 EUR for ACCT1 

Customer pays 200,000/1 .1766 = EUR 169,981 to buy 200,000 USD for ACCT2 

Result: Customer receives $82,310 ($200,000 -$117,690) and pays EUR 69,981 (EUR 169,981- EUR 

100,000) 

With netting: 

Net requirement Is to buy USD and sell EUR 
Bank's rate for this transaction Is 1.1766: 

Customer pays 100.000M.1766 = $117,660 to buy 100,000 EUR for ACCT1 
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Customer pays 200,000/1 .1 766 = EUR 1 69,981 to buy 200,000 USD for ACCT2 
Result Customer receives $82,340 ($200,000 - $117660) and pays EUR69.981 (EUR 169,981- EUR 
100,000) 



As shown in Table 2, the customer again saves $30 by trading the two 
requirements on a netted basis instead of trading them separately. 

5 With reference again to the system depicted in FIG. 1 , batch management 

server 115 takes the requirements provided by the customer and, if necessary, 
rearranges, combines and nets the requirements contained in the set of requirements 
together. In a preferred embodiment, batch management server 115 also receives 
indicative prices for the requirements from indicative price engine 125. Typically, the 

10 batch of orders and indicative prices would then be presented to the customer by user 
interface server 1 10 using online connection 101, STP Adapter 145 and customer 
order management system 140. In response, the customer may request, for example by 
selecting one or more input controls on a display screen provided by the user interface 
server, that one or more orders in the batch be sent to a counterparty for quotes or 

1 5 " execution. If the customer makes this request, batch management server 115 transfers 
the selected orders to trading server 120. 

Trading server 120 receives the batch of orders (which, incidentally, may 
contain multiple orders from the batch, all of the orders, or only one order) and sends 
them to the counterparty-side components of the system via online connection 102. In 

20 a preferred embodiment, trading server 120 is coupled, via online connection 102, to 
counterparty trade management system 155, which comprises one or more application 
programs or processes that allow the counterparty (usually a provider bank) to 
receive and respond to orders, requests for quotes, etc, Thus, the counterparty may 
use counterparty trade management system 155, in accordance with principles of the 

25 present invention, to provide, among other things, quotes for new orders, price 

additions and adjustments for pending orders, and confirmations and trade details for 
booked and/or executed orders. 

As illustrated in FIG. 1, embodiments of the present invention may also 
include a rate engine 150, typically coupled to counterparty trade management system 
30 1 55, configured to automatically generate price quotes for requirements as they are 
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received from trading server 1 20, thereby making it possible for the counterparty to 
instantly and constantly provide accurate and viable quotes for incoming orders 
without human intervention. Thus, the inclusion of rate engine 150 in the system 
typically reduces significantly the time required to propose, book and confirm an 
5 order comprising numerous requirements or a batch of orders. 

In preferred embodiments, optional security server 160 prevents access to the 
system by unauthorized customers and providers. To facilitate and control these 
security measures, security server 160 may be coupled to a security database 165, 
which contains security-related data (e.g., names, account numbers, passwords, etc.) 
1 0 for each customer and each provider. 

The preferred embodiment of the system also includes a transaction database 
135 configured to store transaction messages and details associated with booked 
and/or executed trades. The system may further include hardware and/or software 
processors that utilize messages and details stored in transaction database 135 to 

1 5 implement post-execution-stage matching, confirmation, amendment, settlement and 
liquidity outsourcing functionality. This functionality may be achieved, for example, 
by combining the features of the present invention with the inventions and features 
described in co-pending application Ser. No. 10/463,866, entitled "METHOD AND 
APPARATUS FOR MANAGING FINANCIAL TRANSCATTONS INVOLVING 

20 MULTIPLE COUNTERPARTIES AND PROCESSING DATA PERTAINING 
THERETO," filed on June 18, 2003, and application Ser. No. 10/237,980, entitled 
"METHOD AND APPARATUS FOR AMENDING FINANCIAL 
TRANSACTIONS," filed September 10, 2002, both of which are assigned to the 
assignee of the present application, and which are hereby incorporated herein in their 

25 entirety by this reference. 

FIGS. 2 and 3 illustrate by way of a high-level flow diagram the steps that 
might be performed by an asset trading system configured to operate in accordance 
with an embodiment of the present invention, such as the system shown in FIG. 1, for 
example. As shown in FIG. 2, the process begins at step 205, where a set of 
30 requirements is received from the customer. Typically, the requirements will be 
imported, copied or manually typed into the system, or alternatively, transmitted to 
the system via a customer order management system (OMS) and STP adapter, as 
described above with reference to FIG. 1. At step 210, the set of requirements is 
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arranged to form a batch of orders according to a default or specified set of 
preferences, such as minimum and maximum order totals, preferred hanking accounts, 
value dates, etc. Each order in the hatch comprises a subset of requirements from the / 
set of requirements. The subset may comprise one requirement from the set of 
5 requirements, all of the requirements from the set of requirements, or any number in 
between. 

Next, the batch of orders is displayed to the customer at step 215. The batch 
of orders may be displayed to the customer in a variety of ways and formats. Two 
such formats, referred to herein as the "Allocations View" and "Summary View" are 
10 discussed in detail below with reference to FIGS. 7, 8/12 and 13, Preferably, the 
orders are displayed to the customer along with indicative prices in order to give the 
customer some idea of the current state of the market as it relates to the requirements 
the customer wishes to fulfill. 

As shown at step 220, the system allows the customer to override the default 
1 5 set of preferences by specifying parameters such as new the maximum or minimum 
value of any order. In preferred embodiments, the customer may also choose at this 
point to move or exclude certain requirements from certain orders. Then, in step 225, 
the system receives from the customer information identifying one or more preferred 
counterparties. Such information also may be supplied by reference to a customer 
20 profile 230, which may reside, for example, in an administrative server component of 
the system, or, alternatively, may be provided manually along with the requirements. 

At step 235, the system may refer to an optional administrative server 
component to determine whether the requested transaction is authorized under a set of 
business rules 240, such as, for example, credit limits defined by a counterparty bank, 

25 or government regulations, such as the Employee Retirement Income Security Act 
(ERISA). If the transaction is not authorized, an error message is displayed (step 
250), and processing returns to step 220, where the customer will be allowed to make 
adjustments to the orders in order to bring them into compliance with the scope of 
authority provided by business rules 240. For example, if the order breaks a credit 

30 limit, the user may break the order into two smaller orders (a step 220 activity) and 
request that each order be sent to a different bank (a 225 activity). 
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If, on the other hand, it is determined at step 235, that the requested transaction 
is authorized under business rules 240, then the system, at step 255, determines 
whether a request to send the order to a counterparty for pricing has been received. If 
no such request has been received, then the system simply continues checking for 
5 such a request. If, however, a request to send the order to the provider has been 

received, then processing continues at step 260, where the system determines whether 
the customer also sent a signal or flag indicating that the order contains a detail 
relating to a previous transaction between the customer and the counter party. If die 
signal or flag is not sent, processing continues at step 305 on FIG. 3 by way of flow 

1 0 chart connector FC 1 , where the system sends the batch of orders to the selected 

counterparty (step 305) and receives from the counterparty prices for the orders (step 
310). If, in step 260, it is determined that the signal or flag has been sent, then 
processing continues at step 320 of FIG. 3 by way of flow chart connection FC2, 
where the batch and flag are sent to the counterparty (step 320). At step 325, the 

1 5 system receives additional or adjusted prices from the counterparty to complete the 
order associated with a prior transaction between the counterparty and the customer. 

Next, the system displays the prices for the order to the customer (step 315) 
and determines whether the customer has accepted or rejected the prices (steps 330 
and 345, respectively). If an acceptance is received in step 330, then one or more 

20 trades corresponding to the requirements in the order are executed (step 335) and 
certain trade details, such as account balances, are displayed to the customer (step 
340). Processing then returns to the beginning of the flow diagram (step 205 on FIG. 
2) by way of flow chart connector FC3. If it is determined, however, at step 345, that 
the customer rejected the prices, then the transaction is terminated, and again, 

25 processing returns to the beginning of the flow diagram (step 205 in FIG. 2) by way of 
flow chart connector FC3. 

If, on the other hand, it is determined at steps 330 and 345 that the customer 
has not provided either an acceptance or a rejection, then the system determines if an 
updated price has been received from the counterparty (step 350). If an updated price 
30 has been received, then control returns to step 315, where those updated prices are 
presented to the customer. If no updated price is received, the system determines, at 
step 355, whether a specified time limit has expired. If the specified time limit has 
expired, processing again continues at step 205 on FIG. 2 by way of flow chart 



-24- 



WO 2004/044811 



PCT/US2003/035486 



connector FC3. If the time limit has not expired, then control returns again to step 
330, where the system attempts to determine whether the customer has accepted or 
rejected the prices (steps 330 and 345, respectively). 

FIG. 4 illustrates an example of a user input screen that may be used to copy, 
5 paste and import requirements into a batch trading system configured to operate in 
accordance with principles of the present invention. This screen may be drawn, 
transmitted or presented, for instance, by user interface server 1 10 and customer order 
management system 140 in FIG. 1. As can be seen in the area generally designated 
by reference number 405, the example screen contains, among other things, the 

10 account numbers, currency pairs, dealt currencies, type of transaction ("B" for buy, 
"S" for sell) and value date for a set of trading requirements. In the example shown in 
FIG. 4, seventeen requirements are visible (see the area generally labeled with 
reference number 405). The requirements may be manually typed in by the customer, 
or, alternatively, loaded or pasted from another file or program. Accordingly, the 

15 screen also contains a text input field and control (labeled 410 and 415, respectively), 
which the customer may use to specify and load a file containing additional and/or 
alternative requirements. After loading or manually typing the requirements, the 
customer may transmit the requirements to a batch management server component of 
the invention, such as, for example, by clicking the "Import" button labeled 420 in 

20 FIG. 4. 

FIG. 5 shows an example of a display screen that may be used to present the 
set of requirements after they have been arranged into a batch of orders and 
requirements, along with indicative quotes, before they are submitted to a 
counterparty, such as a bank. FIG. 5 shows fifteen requirements that have been 

25 arranged into three orders (generally labeled 505, 510 and 515). In this case, all of the 
requirements that have the same currency pair and dealt currency are arranged to be in 
the same order. For example, all requirements having a currency pair of EUR.USD 
have been placed in the order designated 505. In addition, the netted value of all of 
the requirements in a particular order has been computed and is displayed at the top of 

30 each order. For instance, the netted value of the five requirements in order 5 1 0 is 

330,00 GBP. Thus, 330,000 GBP (labeled 520 in FIG. 5) is shown at the top of order 
510. Indicative prices for each requirement are also shown in the columns generally 
designated 550. 
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An input field (labeled 525 in FIG. 5) is also provided so that the customer . 
may specify a preferred bank to send the orders. Controls (labeled 530 and 535) are 
provided so that the customer may send one or more orders to the designated bank 
with or without setting the "send details" flag described above with reference to FIGS. 
5 2 and 3. Finally, a control (labeled 540 in FIG. 5) is provided so that the customer 
may send the entire batch (all requirements in all orders on the screen) 
simultaneously. 

The exemplary display screen of FIG. 5, shows all of the requirements in each 
order. This is called an "allocation view" of the batch of orders. By selecting (e.g., 
10 clicking) the control labeled 570 in FIG. 5, the customer may instruct the system to 
combine and net the "sell" requirements in each order, as well as combine and net all 
of the "buy" requirements in each order. The result is the exemplary screen shown in 
FIG. 6, which is called a "summary view" of the batch of orders. 

FIG. 7 shows an allocation view of the requirements after the batch has been 
1 5 submitted to, priced and returned by a bank. As shown in FIG. 7, an actual price 

quote is alongside each requirement (see the column generally labeled 710 in FIG. 7). 
Controls 721 and 730 are provided so that the customer may accept or reject one or 
more orders. Further, controls 740 and 750 are configured to provide a way for the 
customer to accept or Teject, in one click, the entire batch of orders. FIG. 8 shows a 
20 summary view of the batch of orders contained in FIG. 7. 

In FIGS. 4 through 8, the orders are "netted" across requirements that have the 
same currency pair and the same dealt currencies. In FIGS. 9 through 12, however, 
the orders are "netted" across requirements that have the same currency pair and 
different dealt currencies. Thus, for example, FIG. 9 shows an allocations view of a 

25 batch of orders (labeled 905, 9 1 0 and 9 1 5 in FIG. 9) comprising the set of 

requirements, along with indicative quotes (see the columns generally designated 920 
in FIG. 9) for each requirement As shown in FIG. 9, however, each order contains 
' requirements that have different dealt currencies. Order 905, for example, contains 
some requirements that specify EUR as the dealt currency and other requirements that 

30 specify USD as the dealt currency. 

The netted value of requirements having different dealt currencies, shown at 
the top of each order (see 930 in FIG. 9) is calculated according to the indicative price 
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for the exchange rate between the two dealt currencies, the netted value is shown 
with an approximation indicator ("-") to remind the customer that the netted value 
shown is only an approximation based on an "indicative" price, and not an actual 
quote. FIG. 10 shows an example of a summary view of the batch of orders contained 
5 in FIG. 9. 

FIG. 1 1, like FIG. 7, shows an allocation view of the requirements in a batch 
of orders after the batch has been submitted to, priced and returned by a bank. 
However, FIG. 1 1 shows an allocations view for a batch of orders, where there are 
requirements in the orders that have different dealt currencies. Since the bank has 
10 provided actual quotes and the indicative quotes are no longer being used to calculate 
the netted values, the approximation symbol ("~") is not used. FIG. 12 shows an 
example of a summary view of the batch of orders contained in FIG. 1 1 . 

The present invention has been disclosed and described herein in what is 
considered to be its most preferred embodiments. It should be noted that variations 

1 5 and equivalents may occur to those skilled in the art upon reading the present 

disclosure and that such variations and equivalents are intended to come within the 
scope of the invention and the appended claims. Therefore, for example, it should be 
understood by one skilled in the art that the present invention is- not limited to foreign 
exchange transactions, and may be beneficially applied to other types of transactions 

20 as described above. ! 



-27- 



WO 2004/044811 
What is Claimed is: 



CLAIMS 



PCTYUS2003/035486 



1 . A method for trading assets, comprising: 

5 establishing a communications channel with a customer; 

receiving a set of requirements from the customer via the communications 
channel; 

arranging the set of requirements to form a batch of orders, each order in the 
batch comprising a subset of requirements from the set of 
10 requirements; 

automatically providing a quote for an order in the batch, the quote 

comprising a price for executing a group of trades, each trade in the 
group corresponding to a requirement in the order; 

presenting the quote to the customer via the communications channel; 

15 receiving an acceptance for the quote from the customer via the 

communications channel; and 

responsive to the acceptance, booking the group of trades. 

2. The method of claim 1, further comprising receiving from the customer, via 
the communications channel, a request to provide the quote. 

20 3. The method of claim 1 , further comprising confirming the group of trades. 

4, The method of claim 1, further comprising settling the group of trades. 

5. The method of claim 1 , further comprising sending a notice to the customer, 
via the communications channel, indicating that the group of trades has been 
booked. 

25 6. The method of claim 1 , further comprising storing trade details associated with 
the group of trades in a transaction database. 
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7. The method of claim 1, further comprising receiving an instruction from the 
customer, via the communications channel, to modify the subset of requirements 
in the order. 

8. The method of claim 1, further comprising receiving an instruction from the 

5 customer, via the communications channel, to combine two orders in the batch 

to form a new order. 

9. The method of claim 1, wherein the arranging step is carried out using a set of 
preferences. 

10. The method of claim 9, further comprising receiving an instruction from the 
1 0 customer via the communications channel to modify the set of preferences. 

1 1 . The method of claim 9, wherein the set of preferences comprises at least one 
of the following: 

a maximum value for an order; and 

a minimum value for an order. 

15 12. The method of claim 1 , wherein: 

the set of requirements comprises at least two requirements having a particular 
currency pair; and 

the arranging step comprises assigning the at least two requirements to the 
same order. 

20 13. The method of claim 1 6 , further comprising computing a netted value for the 
at least two requirements. 

14. The method of claim 1 6, wherein the at least two requirements do not have the 
same dealt currency. 

15. The method of claim 18, further comprising computing a netted value for the 
25 at least two requirements, 

1 6 . The method of claim 1 , wherein: 
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the set of requirements comprises at least two requirements associated with a 
particular account; and 

the arranging step comprises assigning the at least two requirements to the 
same order. 

17. The method of claim 16, further comprising computing a netted value for the 
at least two requirements. 

18. The method of claim 1, wherein: . 

the set of requirements comprises at least two requirements having a particular 
value date; and 

the arranging step comprises assigning the at least two requirements to the 
same order. 

1 9. The method of claim 1 8, further comprising computing a netted value for the 
at least two requirements. 

20. The method of claim 1 , wherein: 
the set of requirements comprises 

a first requirement comprising a proposal to buy or sell a security, and 

a second requirement comprising a proposal to exchange one currency 
for another currency; and 

the arranging step comprises assigning the first requirement and the second 
requirement to the same order. 

21 . The method of claim 16, further comprising computing a netted value for the 
first requirement and the second requirement. 

22. The method of claim 1 , further comprising generating an indicative price for 
executing a trade in the group of trades. 
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23. The method of claim 22, wherein the step of generating the indicative price is 
carried out using an indicative price engine. 

. 24. The method of claim 1, further comprising automatically generating at least 
one quote for every order in the batch to form a collection of quotes. 

5 25 . The method of claim 24, further comprising: 

presenting the collection of quotes to the customer via the communications 
channel; and 

receiving from the customer, via the communications channel, an instruction 
to accept the collection of quotes. 

10 26. The method of claim 1, further comprising receiving from the customer a 
request to send the order to a counterparty. 

27. The method of claim 22, wherein the counterparty comprises a bank. 

28. The method of claim 26, wherein the counterparty comprises a broker. 

29. The method of claim 26, wherein the request includes an indication that the 

1 5 order comprises a detail associated with a prior transaction between the customer 

and the counterparty. 

30. The method of claim 29, further comprising receiving from the counterparty 
an additional term for the prior transaction. 

3 1 . The method of claim 30, wherein the additional term comprises a trading 
20 price. 

32. The method of claim 30, wherein the additional term comprises a price 
adjustment. 

33. The method of claim 1, further comprising transmitting the batch to the 
customer via the communications channel. 

25 34. The method of claim 1 , wherein the step of automatically providing a quote 
comprises: 
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establishing a second communications channel with a counterparty; 

presenting the order to the counterparty via the second communications 
channel; and 

receiving the quote from the counterparty via the second communications 
5 channel. 

35. The method of claim 34, further comprising: 

transmitting the acceptance to the counterparty via the second 
communications channel; 

receiving a confirmation from the counterparty responsive to the acceptance; 
10 * and 

sending the confirmation to the customer via the communications channel, 

36. The method of claim 35, further comprising sending a notice to the 
counterparty, via the second communications channel, indicating that the group 
of trades has been booked. 

15 37. The method of claim 1 , further comprising receiving from the customer an 
instruction identifying a preferred counterparty for the order. 

38. The method of claim 37, further comprising presenting the order to the 
preferred counterparty. 

39. The method of claim 24, further comprising receiving from the customer an 
20 instruction identifying a preferred counterparty for each order in the batch. 

40. The method of claim 39, further comprising presenting each order in the batch 
to the preferred counterparty for said each order. 

4 1 . The method of claim 1 , wherein the communications channel comprises an 
Internet connection. 

25 42. The method of claim 1 , wherein the communications channel comprises a 
wide area network connection. 
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43. The method of claim 1, wherein the communications channel comprises a 
local area network connection. 

44. The method of claim 1, wherein the communications channel comprises a 
telephone connection. 

5 45. The method of claim 1, wherein the subset of requirements includes a proposal 
to exchange one currency for another currency. 

46. The method of claim 1, wherein the subset of requirements includes a proposal 
to lend or borrow a sum of money. 

47. The method of claim 1, wherein the subset of requirements includes a proposal 
1 0 to buy or sell a commodity. 

48. The method of claim 1, wherein the subset of requirements includes a proposal 
to buy or sell a security. 

49. A method for trading assets, comprising: 

establishing a communications channel with a customer; 

1 5 receiving a set of requirements from the customer via the communications 

channel; 

arranging the set of requirements to form a batch of orders, each order in the 
batch comprising a subset of requirements in the set of requirements; 

repeiving from the customer a request book an order in the batch; 

20 responsive to the request, booking a trade in a group of trades, each trade in 

the group corresponding to a requirement in the order; and 

transmitting to the customer a booking detail for the group of trades. 

50. The method of claim 49, wherein the booking detail is transmitted to the 
customer via the communications channel. 



-33- 



WO 2004/044811 PCT/US2003/035486 

5 1 . The method of claim 49, wherein the request includes an instruction to execute 
the group of trades at a best available price. 

52. The method of claim 49, further comprising confirming the group of trades. 

53. The method of claim 49, further comprising settling the group of trades. 

5 54. The method of claim 49, further comprising sending a notice to the customer 
indicating that the group of trades has been booked. 

55. The method of claim 52, further comprising sending an execution detail to the 
customer. 

56. The method of claim 49, wherein the arranging step is carried out using a set 
10 of preferences. 

i 

57. The method of claim 56, further comprising receiving an instruction from the 
customer to modify the set of preferences. 

58. The method of claim 56, wherein the set of preferences comprises at least one 
of the following: 

15 a maximum value for an order; and 

a minimum value for an order. 

59. The method of claim 58, wherein the request comprises an instruction to send 
the order to a counterparty. 

60. The method of claim '59, wherein the counterparty comprises a bank. 
20 61. The method of claim 60, wherein the counterparty comprises a broker. 

62. The method of claim 49, wherein the request includes an indication that the 
order comprises a detail associated with a prior transaction between the customer 
and the counterparty. 

63. The method of claim 62, further comprising receiving from the counterparty 
25 an additional term for the prior transaction. 
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64. The method of claim 63, wherein the additional term comprises a trading 
price. 

65 . The method of claim 63 , wherein the additional term comprises a price 
adjustment 

66. The method of claim 49, wherein the communications channel comprises an 
Internet connection. 

67. The method of claim 49, wherein the communications channel comprises a 
wide area network connection. 

68. The method of claim 49, wherein the communications channel comprises a 
local area network connection. 

69. The method of claim 45, wherein the communications channel comprises a 
telephone connection. 

70. The method of claim 49, wherein a requirement in the set of requirements 
comprises a proposal to exchange one currency for another currency. 

7 1 . The method of claim 49, wherein a requirement in the set of requirements 
comprises a proposal to lend or borrow a sum. of money. 

72. The method of claim 49, wherein a requirement in the set of requirements 
comprises a proposal to buy or sell a commodity. 

73 . The method of claim 49, wherein a requirement in the set of requirements 
comprises a proposal to buy or sell a security. 

74. A method for trading assets, comprising: 

receiving a set of requirements from a customer via a communications 
channel; 

arranging the set of requirements to form a batch of orders, each order in the 
batch comprising a subset of requirements in the set of requirements; 
and 
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automatically booking a group of trades, each trade in the group 
corresponding to a requirement in an order. 

75. The method of claim 74, further comprising confirming the group of trades. 

76. The method of claim 74, further comprising settling the group of trades. 

5 77. The method of claim 74, further comprising sending a notice to the customer, 
via the communications channel, indicating that the group of trades has been 
booked. 

78. The method of claim 74, further comprising storing transaction details 
associated with the group of trades in a transaction database. 

10 79. The method of claim 74, wherein the arranging step is carried out using a set 
of preferences. 

80. The method of claim 79, further comprising receiving an instruction from the 
customer, via the communications channel, to modify the set of preferences. 

81 . The method of claim 79, wherein the set of preferences comprises at least one 
15 of the following: 

a maximum value for an order; and 

a minimum value for an order. 

82. The method of claim 74, wherein: 

the set of requirements comprises at least two requirements having a particular 
20 currency pair; and 

the arranging step comprises assigning the at least two requirements to the 
same order. 

83. The method of claim 82, further comprising computing a netted value for the 
at least two requirements. 
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„ -—84 Thejnethod_of claim 82, wherein.the at least two requirements donot have_the 

same dealt currency. 

85. The method of claim 84, further comprising computing a netted value for the 
at least two requirements. 

5 86. The method of claim 74, wherein: 

the set of requirements comprises at least two requirements associated with a 
particular account; and 

the arranging step comprises assigning the at least two requirements to the 
same or<ier, 

10 87. The method of claim 86, further comprising computing a netted value for the 
at least two requirements. 

88. The method of claim 74, wherein: 

the set of requirements comprises at least two requirements having a particular 
value date; and 

15 the arranging step comprises assigning the at least two requirements to the 

same order. 

89. The method of claim 88, further comprising computing a netted value for the 
at least two requirements, 

90 . The method of claim 8 5 , wherein: 
20 the set of requirements comprises 

a first requirement comprising a proposal to buy or sell a security, and 

a second requirement comprising a proposal to exchange one currency 
for another currency; and 

the arranging step comprises assigning the first requirement and the second 
25 requirement to the same order. 
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91._ The meth od of cla im 90, further comprising com putin g a netted value for the . 

first requirement and the second requirement. 

92. A method of interacting with a computer system so as to trade assets, 
comprising: 

5 launching an order management system that includes a command to establish 

a communications channel with the computer system; 

providing a set of requirements to the computer system via the order 
management system; 

invoking a command in the order management system so as to cause the 
10 computer system to generate a batch of orders, each order in the batch 

comprising a subset of requirements from the set of requirements; 

selecting a control in the order management system so as to cause the 

computer system to provide a quote for collectively executing a group 
of trades to fulfill every requirement in at least one order in the batch; 
15 and 

issuing an instruction, via the order management system, to accept the quote. 

93 . The method of claim 92, further comprising receiving a notice, via the 
communications channel, indicating that the group of trades has been executed. 

94. The method of claim 92, further comprising executing a command in the order 
20 management system to provide a set of preferences associated with the group of 

trades. 

95. The method of claim 92, further comprising selecting another control 
configured to cause the computer system to send the order to a counterparty. 

96. The method of claim 95, wherein the counterparty comprises a bank. 
25 97. The method of claim 95, wherein the counterparty comprises a broker. 
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98. The method of claim 92, further comprising selecting a button configured to 
cause the computer system to provide a signal indicating that the order comprises 
a detail associated with a prior transaction. 

99. The method of claim 92, wherein the subset of requirements includes a 
5 proposal to exchange one currency for another currency. 

100. The method of claim 92, wherein the subset of requirements includes a 
proposal to lend or borrow a sum of money. 

101. The method of claim 92, wherein the subset of requirements includes a 
proposal to buy or sell a commodity. 

10 1 02. The method of claim 92, wherein the subset of requirements includes a 
proposal to buy or sell a security. 

103. An asset trading system, comprising: 

a communications channel for receiving a set of requirements from a 
customer; 

15 a batch manager configured to arrange the set of requirements into a batch of 

orders, each order in the batch comprising a subset of requirements 
from the set of requirements; 

a trading server configured to provide a quote for an order in the batch, the 

quote comprising a price for executing a group of trades, each trade in 
20 the group corresponding to a requirement in the order; and 

a user interface configured to present the quote to the customer via the 

communications channel and to receive an acceptance for the quote 
from the customer via the communications channel; 

wherein, responsive to the acceptance, the trading server is configured to book 
25 the group of trades. 
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104. The system of claim 103, wherein the user interface is further configured to 
receive from the customer, via the communications channel, a request to provide 
the quote. 

105. The system of claim 103, further comprising a post-execution-stage processor 
5 configured to confirm the group of trades. 

106. The system of claim 103, further comprising a post-execution-stage processor 
configured to settle the group of trades. 

107. The system of claim 1 03, wherein the user interface is further configured to 
send a notice to the customer, via the communications channel, indicating that the 

1 0 group of trades has been booked. 

1 08. The system of claim 103, wherein the batch manager is configured to arrange 
the set of requirements according to a set of preferences. 

1 09. The system of claim 108, wherein the user interface is further configured to 
receive an instruction from the customer, via the communications channel, to 

1 5 modify the set of preferences. 

1 10. The system of claim 108, wherein the set of preferences comprises at least one 
of the following: 

a maximum value for an order; and 

a minimum value for an order. 

20 111. The system of claim 1 08, further comprising an administrative server 
configured to store the set of preferences. 

1 12. The system of claim 103, wherein: 

the set of requirements comprises at least two requirements having a particular 
currency pair; and 

25 the batch manager is further configured to assign the at least two requirements 

to the same order. 
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113. The system of claim 112, wherein the batch manager is further configured to 
compute a netted value for the at least two requirements. 

1 14. The system of claim 1 12, wherein the at least two requirements do not have 
the same dealt currency. 

5 115, The system of claim 1 1 4, wherein the batch manager is further configured to 
compute a netted value for the at least two requirements. 

116, The system of claim 1 03, wherein: 

the set of requirements comprises at least two requirements associated with a 
particular account; and 

10 the batch manager is further configured to assign the at least two requirements 

to the same order. 

1 17; The system of claim 1 16, wherein the batch manager is further configured to 
compute a netted value for the at least two requirements. 

1 18. The system of claim 103, wherein: 

1 5 the set of requirements comprises at least two requirements having a particular 

value date; and 

the batch manager is further configured to assign the at least two requirements 
to the same order. 

1 19. The system of claim 118, wherein the batch manager is further configured to 
20 compute a netted value for the at least two requirements. 

120. The system of claim 103, wherein: 
the set of requirements comprises 

a first requirement comprising a proposal to buy or sell a security, and 

a second requirement comprising a proposal to exchange one currency 
25 for another currency; and 
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the batch manager is further configured to assign the first requirement and the 
second requirement to the same order. 

121 . The system of claim 120, wherein the batch manager is further configured to 
compute a netted value for the first requirement and the second requirement. 

5 122. The system of claim 103, further comprising an indicative price engine 
configured to generate indicative prices for executing the group of trades. 

123. The system of claim 122, wherein the indicative price engine is 
communicatively coupled to the batch manager. 

124. The system of claim 103, the batch manager is further configured to form a 

1 0 collection of quotes by generating at least one quote for every order in the batch. 

125. The system of claim 124, wherein the user interface is further configured: 

to present the collection of quotes to the customer via the communications 
channel; and 

to receive from the customer, via the communications channel, an instruction 
15' to accept the collection of quotes. 

126. The system of claim 103, wherein the user interface is further configured to 
receive from the customer a request to send the order to a counterparty. 

127. The system of claim 126, wherein the counterparty comprises a bank. 

128. The system of claim 126, wherein the counterparty comprises a broker. 

20 129. The system of claim 126, wherein the request includes an indication that the 
order comprises a detail associated with a prior transaction between the customer 
and the counterparty. 

130. The system of claim 129, wherein the trading server is further configured to 
receive from the counterparty an additional term for the prior transaction. 

25 131. The system of claim 1 30, wherein the additional term comprises a trading 
price. 
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132. The system of claim 130, wherein the additional term comprises a price 
adjustment. 

133. The system of claim 103, wherein the user interface is further configured to 
display the batch to the customer via the communications channel. 

5 134. The system of claim 103, further comprising a second communications 

channel, coupled to the trading server, configured to convey the order from the 
trading server to a counterparty. 

135. The system of claim 134, wherein the second communications channel is 
further configured to convey the quote from the counterparty to the trading 

10 server. 

136. The system of claim 134, wherein the second communications channel is 
further configured to convey the acceptance from the trading server to the 
counterparty. 

137. The system of claim 125, wherein the second communications channel is 

1 5 further configured to convey a confirmation responsive to the acceptance from 

the counterparty to the trading server, 

138. The system of claim 136, wherein the trading server is further configured to 
send a notice to the counterparty, via the second communications channel, 
indicating that the group of trades has been booked. 

20 139. The system of claim 103, wherein the user interface is further configured to 
receive from the customer an instruction identifying a preferred counterparty for 
the order. 

140. The system of claim 139, wherein the trading server is further configured to 
transmit the order to the preferred counterparty. 

25 141. The system of claim 124, wherein the user interface is further configured to 
• receive from the customer an instruction identifying a preferred counterparty for 
each order in the collection. 
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142. The system of claim 141, wherein the trading server is further configured to 
transmit each order in the collection to the preferred counterparty for said each 
order. 

143. The system of claim 103, wherein the communications channel comprises an 
5 Internet connection. 

144. The system of claim 134, wherein the second communications channel 
comprises an Internet connection. 

145. The system of claim 103, wherein the communications channel comprises a 
wide area network connection. 

10 1 46. The system of claim 134, wherein the second communications channel 
comprises a wide area network connection. 

147. The system of claim 103, wherein the communications channel comprises a 
local area network connection. 

148. The system of claim 134, wherein the second communications channel 
1 5 comprises a local area network connection. 

149. The system of claim 103, wherein the communications channel comprises a 
telephone connection. 

1 5b. The system of claim 134, wherein the second communications channel 
comprises a telephone connection. 

20 151. The system of claim 103, wherein the subset of requirements includes a 
proposal to exchange one currency for another currency. 

1 52. The system of claim 103, wherein the subset of requirements includes a 
proposal to lend or borrow a sum of money. 

153. The system of claim 103, wherein the subset of requirements includes a 
25 proposal to buy or sell a commodity. 

154. The system of claim 103, wherein the subset of requirements includes a 
proposal to buy or sell a security. 
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155. The system of claim 103, further comprising a transaction database configured 
to store transaction details associated with the group of trades. 

156. The system of claim 109, further comprising an administrative server 
configured to store the set of preferences for the customer. 

5 1 57. The system of claim 1 56, wherein the administrative server is further 
configured to store a set of trading rules associated with the customer. 

158. The system of claim 1 03, further comprising an order management system 
configured to receive input directly from the customer under the control of the 
user interface server. 

10 159. The system of claim 1 58, wherein the customer trade management system 
comprises a straight-though processing adapter. 

160. The system of claim 103, further comprising a counterparty trade management 
system configured to receive input directly from the counterparty under the 
control of the trading server. 

15 161. The system of claim 1 60, wherein the counterparty trade management system 
comprises a rate engine configured to generate the actual price for each 
requirement in the set of requirements. 

162. The system of claim 103, further comprising a security server configured to 
prevent unauthorized access to the user interface'. 

20 163. The system of claim 1 62, wherein the security server is coupled to a security 
database comprising security-related data associated with the customer, 

164. The system of claim 103, further comprising a security server configured to 
prevent unauthorized access to the trading server. 

1 65. The system of claim 1 64, wherein the security server is coupled to a security 
25 database comprising security-related data associated with a counterparty. 

166. A user interface for trading assets on a computer system, the user interface 
being invocable via an order management system, comprising: 
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a first display screen configured to receive input including a set of 
requirements from a customer; and 

a second display screen configured to display, responsive' to the input 

a batch of orders, each order in the batch comprising a subset of 
5 requirements from the set of requirements, 

a quote for each order in the batch, each quote comprising a price for 
executing a group of trades, each trade in the group corresponding 
to a requirement in the subset of requirements, and 

a user-activatible control configured to cause the computer system to 
1 0 collectively execute the group of trades. 

1 67, The user interface of claim 166, wherein an order in the batch comprises all of 
the requirements in the set of requirements having a particular currency pair. 

168. The user interface of claim 166, wherein an order in the batch comprises all of 
the requirements in the set of requirements associated with a particular account. 

15 169. The user interface of claim 166, wherein an order in the batch comprises all of 
the requirements in the set of requirements having a particular value date. 

170. A system for trading assets, comprising: 

means for receiving a set of requirements from a customer; 

means for arranging the set of requirements to form a batch of orders, each 
20 order in the batch comprising a subset of requirements in the set of 

requirements; 

means for providing a quote for an order in the batch, the quote comprising 
prices for collectively executing a group of trades, each trade in the 
group corresponding to a requirement in the order; and 

25 means for booking the group of trades. 
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171 . The system of claim 170, further comprising means for executing the group of 
trades. 

172. The system of claim 170, further comprising means for sending a notice to the 
customer indicating that the group of trades has been booked. 

5 1 73 . The system of claim 170, further comprising means for storing transaction 
details associated with the group of trades in a database. 

174. The system of claim 170, wherein the means for arranging operates according 
to a set of preferences. 

175. The system of claim 1 74, further comprising means for receiving an 

10 instruction from the customer, via the means for receiving, to modify the set of 

preferences. 

176. The system of claim 174, further comprising means for receiving an 
instruction from the customer, via the means for receiving, to re-arrange the batch 
of orders. 

15 
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5 USING DIGITAL SIGNATURES TO VALIDATE 
TRADING AND STREAMLINE SETTLEMENT OF 
FINANCIAL TRANSACTION WORKFLOW 

Inventor(s): James E. Kleckner 

10 

BACKGROUND 

15 Field of the Invention 

The present invention relates to computer-based systems for trading financial 
instruments. More specifically, the present invention relates to a method and an 
apparatus that uses digital signatures in validating trading and settlement operations 
involved in a financial transaction, such as a foreign exchange transaction. 

20 

Related Art 

The foreign exchange market is the largest and most liquid market in the world. 
In 1998, the Federal Reserve Bank of New York estimated, that daily turnover was 
approximately $1.5 trillion. 
25 Unlike stocks, which are market-traded, foreign exchange is primarily an 

over-the-counter market. There is no such thing as a "price" for a particular transaction. 
Rather, each dealer, bank, broker, or other trading source, provides their own rate for 
each transaction. 
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The trading and settlement processes for a typical foreign exchange transaction 
are illustrated in FIG. 1. A trader 102, working on behalf of a corporation or other entity, 
makes a quote request 106 to a trader 104, working on behalf of a bank. In response to 
this quote request, trader 104 makes a quote 108 proposing a rate for the transaction. 
5 Trader 1 02 accepts the quote by sending an acceptance message to trader 1 04, in 

which case trader 104 typically sends an acknowledgement message 112 back to trader 
102. 

Note that the communication process outlined above typically takes place over the 
telephone or via facsimile. 
10 After traders 102 and 104 agree to the terms of the transaction, trader 102 

communicates trade information to settlement clerk 118, who works on behalf of the 
same organization as trader 102. Similarly, trader 104 communicates trade information 
1 16 to settlement clerk 120, who works on behalf of the same organization as trader 104. 
Settlement clerks 118 and 120 are responsible for actually causing funds to be 
1 5 transferred between accounts of the two organizations involved in the trade. Before 

doing so, settlement clerks 118 and 120 communicate and confirm settlement information 
122 with each other. This settlement information 122 confirms the terms of the trade, 
and additionally specifies the accounts between which funds are to be transferred. 
Note that settlement clerks 1 1 8 and 120 typically communicate settlement 
20 information 122 via telephone or facsimile. In some cases, this settlement information is 
communicated through a third party payment matching system 128. 

After the settlement information is communicated, and if the terms of the deal are 
in agreement, settlement clerk 118 communicates with funds transfer agent 126, who 
actually transfers the funds. Similarly, settlement clerk 120 communicates with funds 
25 transfer agent 124 to transfer funds in the reverse direction. 

Note that the separation of roles between trading and settlement provides a 
measure of protection against fraud because collusion between a trader and a settlement 
clerk is required to perpetrate most types of fraud. However, this protection has a price, 
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because the many manual communications, validations, and confirmations involved in 

the role-based trading and settlement processes are time-consuming and expensive. 

t 

Also note that the trade terms and settlement instructions are typically entered 
manually on both sides of the transaction. Consequently, the trade terms and settlement 
5 instructions axe often not entered in the same way, and may not match. Even if the trade 
terms and settlement instructions are entered properly, netting and aggregation can cause 
trades not to match. If trades do not match, a great amount of additional work is required 
to sort out inconsistencies. 

What is needed is a method and an apparatus for facilitating trading and 
10 settlement of financial instruments, such as currencies, without the time-consuming 
manual processes involved in existing trading, settlement, and confirmation processes. 



15 SUMMARY 

One embodiment of the present invention provides a system that uses digital 
signatures in performing validations to facilitate a trade. This system operates by 
receiving a quote related to the trade at a first computer system, wherein the quote 
includes signed permission information that facilitatesverifying permissions that have 

20 been granted to a quote maker. Upon receiving the quote, the system validates that the 
quote maker digitally signed the quote by using a public key of the quote maker to verify 
that the quote was signed by a corresponding private key belonging to the quote maker. 
The system also validates that the quote maker has permission to perform the trade by 
using a public key of a first security officer to verify that the permission information was 

25 signed by a corresponding private key belonging to the first security officer, thereby 
authorizing the quote maker to perform the trade. The system records acceptance of the 
quote by signing appropriate fields of the quote with a private key belonging to a quote 
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receiver, and communicating a trade record, including the signed quote, to the quote 
maker. 

In one embodiment of the present invention, the system additionally validates the 
identity of the quote maker and quote receiver by using a public key of a certification 
5 authority to verify that a certificate containing the public key of the quote maker or quote 
receiver was signed by a corresponding private key belonging to the certification 
authority. Note that signing by the certification authority indicates that the certification 
authority has verified the identity of the quote maker and quote receiver. 

In one embodiment of the present invention, the quote includes multiple quotes 
10 from multiple quote makers, which have been aggregated into by a trade facilitator. 

In one embodiment of the present invention, communicating the trade record to 
the quote maker involves sending the trade record to the trade facilitator, who forwards 
the trade record to the quote maker. 

In one embodiment of the present invention, prior to receiving the quote at the 
1 5 first computer system, the system communicates a quote request from the quote receiver 
to the quote maker. This quote request includes information that allows the quote maker 
to validate the identity of the quote receiver. It also includes information that allows the 
quote maker to validate that the quote receiver has permission to perform the trade by 
using a public key of a second security officer associated with the quote receiver to verify 
20 that permission information within the quote request was signed by a corresponding 
private key belonging to the second security officer, thereby authorizing the quote 
receiver to perform the trade. 

In one embodiment of the present invention, in accepting the quote, the system 
additionally sends the trade record to a settlement clerk associated with the quote receiver 
25 who is responsible for settling the trade. 

In one embodiment of the present invention, prior to receiving the quote, the 
system allows the quote maker to obtain permission to make the trade. The quote maker 
does so by sending a request for permission to the first security officer associated with 
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the quote maker. This allows the first security officer to digitally sign a permission 
record to indicate the quote maker has permission to trade. 

In one embodiment of the present invention, the trade involves foreign exchange 
and the trade record includes: a trade date, an identifier for a first currency, a first 
5 currency amount, an identifier for a first organization providing the first currency, an 
identifier for a second currency, a second currency amount, and an identifier for a second 
organization providing the second currency. 

One embodiment of the present invention provides a system that uses digital 
signatures in performing validations to facilitate a trade. This system operates by 

10 receiving a trade record from a quote receiver who has accepted a quote and has thereby 
created the trade. This trade record is received by a first settlement clerk associated with 
the quote receiver, who is responsible for settling the trade. Next, the system augments 
the trade record with settlement instructions identifying at least one account to be used in 
settling the trade, and then signs the relevant fields of the trade record with a private key 

15 belonging to the first settlement clerk. The system then communicates the trade record to 
a second settlement clerk associated with a quote maker. 

In one embodiment of the present invention, upon receiving the trade record at the 
second settlement clerk, the system uses a public key belonging to the first settlement 
clerk to validate that the first settlement clerk has signed the relevant fields of the trade 

20 record. The system also validates that the first settlement clerk has been granted 

permission to settle the trade by examining permission information contained within the 
trade record to verify that a first security officer associated with the first settlement clerk 
has digitally signed the permission information, thereby authorizing the first settlement 
clerk to settle the trade. Next, the system communicates the trade to a funds transfer 

25 agent to carry out the trade. 

In one embodiment of the present invention, communicating the trade record to 
the second settlement clerk involves sending the trade record to a trade facilitator. This 



WO 02/39401 



PCT/US01/31643 



6 

trade facilitator augments the trade record with the permission information for the first 
settlement clerk, and then forwards the trade record to the second settlement clerk. 

In one embodiment of the present invention, the settlement instructions include: 
an identifier for a first account belonging to the first organization; and an identifier for a 
5 second account belonging to the second organization. 

One embodiment of the present invention provides a system that uses digital 
signatures in performing validations to facilitate a trade. This system operates by 
receiving a quote request from a quote requester at a computer system belonging to a 
trade facilitator. Next, the system looks up a trading permission for the quote requester 
10 from a database maintained by the trade facilitator, and appends the trading permission to 
the quote request to form a trade record. Next, the system communicates the trade record 
to potential quoting entities. 

Upon receiving quotes from the potential quoting entities, the system augments 
the trade record to include the quotes, and then sends the augmented trade record to the 
15 quote requester. 

In one embodiment of the present invention, the system additionally receives a 
selection of a quote from the quote requester, and notifies each of the quoting entities 
about whether the quote they made was selected. 

In one embodiment of the present invention, the system receives a trade record 
20 from a first settlement clerk associated with the quote requester. This record includes 
settlement instructions appended to the trade record by the first settlement clerk. Upon 
receiving the trade record, the system looks up permission information for the first 
settlement clerk in a database, and then augments the trade record with the permission 
information for the first settlement clerk. Next, the system forwards the trade record to a 
25 second settlement clerk associated with a quote maker. This allows the second settlement 
clerk to validate the permission information by verifying that the permission information 
was signed with a private key belonging to a first security officer associated with the first 
settlement clerk, thereby authorizing the first settlement clerk to settle the trade. 
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Note that in the case that all permissions and signatures are valid, the first and 
second settlement clerks may be reliably replaced by automated processes, reserving 
human intervention for the exceptional cases. 

5 BRIEF DESCRIPTION OF THE FIGURES 

FIG. 1 illustrates typical trading and settlement processes. 

FIG. 2 illustrates an exchange that facilitates automated trading and settlement in 
accordance with an embodiment of the present invention. 

FIG. 3 illustrates how credentials and permissions are granted in accordance with 
10 an embodiment of the present invention. 

FIG. 4 is a flow chart illustrating the process of obtaining a credential from a 
certification authority in accordance with an embodiment of the present invention. 

FIG. 5 is a flow chart illustrating how a security officer obtains authority to grant 
permissions in accordance with an embodiment of the present invention. 
1 5 FIG. 6 is a flow chart illustrating the process of obtaining a permission from a 

security officer in accordance with an embodiment of the present invention. 

FIG. 7 is a flow chart illustrating the process of facilitating a trade in accordance 
with an embodiment of the present invention. 

FIG. 8 is a flow chart illustrating the process of settling a trade in accordance with 
20 an embodiment of the present invention. 

FIG. 9 illustrates the structure of a trade record in accordance with an 
embodiment of the present invention. 



25 

DETAILED DESCRIPTION 

The following description is presented to enable any person skilled in the art to 
make and use the invention, and is provided in the context of a particular application and 
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its requirements, Various modifications to the disclosed embodiments will be readily 
apparent to those skilled in the art, and the general principles defined herein may be 
applied to other embodiments and applications without departing from the spirit and 
scope of the present invention. Thus, the present invention is not intended to be limited 
5 to the embodiments shown, but is to be accorded the widest scope consistent with the 
principles and features disclosed herein. 

The data structures and code described in this detailed description are typically 
stored on a computer readable storage medium, which may be any device or medium that 
can store code and/or data for use by a computer system. This includes, but is not limited 
10 to, magnetic and optical storage devices such as disk drives, magnetic tape, CDs 

(compact discs) and DVDs (digital versatile discs or digital video discs), and computer 
instruction signals embodied in a transmission medium (with or without a carrier wave 
upon which the signals are modulated). For example, the transmission medium may 
include a communications network, such as the Internet. 

15 

Exchange System 

FIG. 2 illustrates an exchange 200 that facilitates automated trading and 
settlement in accordance with an embodiment of the present invention. Exchange 200 
facilitates trades between treasury systems 202-204 and trading systems 208-210. 

20 Exchange 200 can additionally be coupled to a number of other exchanges 206-207. 
Note that exchange 200, treasury systems 202-204 and trading systems 208-210 run on 
computer systems. These computer systems can generally include any type of computer 
system, including, but not limited to, a computer system based on a microprocessor, a 
mainframe computer, a digital signal processor, a portable computing device, a personal 

25 organizer, a device controller, and a computational engine within an appliance. 

Also note that linkages show in FIG. 2 pass across one or more computer 
networks (not shown). These networks generally include any type of wire or wireless 
communication channel capable of coupling together computing nodes. This includes, 
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but is not limited to, a local area network, a wide area network, or a combination of 
networks. In one embodiment of the present invention, the network includes the Internet. 

Treasury systems 202-204 generally belong to organizations requiring foreign 
exchange services, such as corporations, funds or non-governmental organizations 
5 (NGOs) but could also include banks requesting trades. Hence, treasury systems 202-204 
generally request quotes for from trading systems 208-21 0, and accept quotes from 
trading systems 208-210. 

Trading systems 208-210 generally belong to banks providing foreign exchange 
services but could include other organizations that choose to act as quote makders. 
10 Hence, trading systems 208-210 generally receive quote requests from treasury systems 
202-204, and make quotes to be accepted by treasury systems 202-204. 

Treasury systems 202-204 are coupled to one or more funds transfer agents, such 
as funds transfer agent 220, which carry out instructions to actually transfer funds 
between accounts. Similarly, trading systems 208-210 are coupled to one or more funds 
15 transfer agents, such as funds transfer agent 221 . Note that fluids transfer agents 220 and 
221 may be the same funds transfer agent. 

Exchange 200 communicates secure, authenticated quote requests, quotes and 
quote acceptances between treasury systems 202-204 and trading systems 208-210. 
Exchange 200 also facilitates communication of settlement instructions between treasury 
20 systems 202-204 and trading systems 208-210. These functions are described in more 
detail with reference to FIGs. 3-9 below. 

Note that exchange 200 can additionally be coupled to exchanges 206-207 to 
facilitate cross-exchange transactions. 

25 Granting of Credentials and Permissions 

FIG. 3 illustrates how credentials and permissions are granted in accordance with 
an embodiment of the present invention. In FIG. 3, organization 302 trades with 
organization 304 through exchange 200. Certification authority 320 is an independent. 
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entity that verifies the identity of users and grants credentials for use by various actors 
belonging to organizations 302-304 and to exchange organization 306. 

More specifically, organization 302 includes treasury system 202, which 
communicates with exchange 200. Treasury system 202 operates under control of user 
5 310, such as a front office trader, who receives permissions from a local security officer 
312, who also is associated with organization 302. Organization 302 also includes a 
settlement clerk 311, who is responsible for settling trades made by user 310. 

Similarly, organization 304 includes trading system 208, which communicates 
with exchange 200. Trading system 208 operates under control of user 318, who receives 
10 permissions from a local security officer 316, who is also associated with organization 
304. Organization 304 also includes a settlement clerk 3 19, who is responsible for 
settling trades made by user 318. 

Exchange organization 306 includes exchange 200 as well as security officer 314, 
who confers permission granting authority to local security officers 312 and 316. Note 
15 that exchange 200 is coupled to a database 301, which contains permission table 305. 
Permission table 305 contains permissions for users 3 10 and 3 1 8, security officers 3 12 
and 3 1 6, and settlement clerks 3 1 1 and 3 1 9. 

All of the above-described entities receive credentials from independent 
certification authority (C A) 320, which grants credentials to users 3 1 0 and 3 1 8, security 
20 officers 312,314 and 3 1 6, and settlement clerks 3 1 1 and 319. This credential granting 
process is described below with reference to FIG. 4. 

During operation of the system illustrated in FIG. 3, CA 320 generates credentials 
330-334 that are used by actors, such users 3 10 and 3 1 8, security officers 3 12, 3 14 and 
316 and settlement clerks 311 and 3 1 9 to validate identities. 
25 In addition to validating identities, the system illustrated in FIG. 3 validates 

permissions to perform operations, such as trading and settling trades. Security officer 
314, who belongs to exchange organization 306, confers permission granting authority on 
security officers 312 and 316 belonging to organizations 302 and 304, respectively. 
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Security officers 312 and 316 in turn grant trading permissions 340 and 341 to users 310 
and 3 1 8, respectively. Security officers 3 1 2 and 3 1 6 can also grant settlement 
permissions 342 and 343 to settlement clerks 311 and 319, respectively. Note that users 
310 and 318 require both permissions and credentials in order to perform actions, such as 
5 trading and settling trades. 

Process of Obtaining a Credential 

FIG. 4 is a flow chart illustrating the process of obtaining a credential 330 from a 
certification authority 320 for a user 3 10 in accordance with an embodiment of the 
10 present invention. The process starts when user 3 10 requests a credential 330 from 

currency exchange (CX) 200 (step 402). (Note that this credential is also referred to as a 
digital certificate.) In response to the request, CX 200 instructs user 3 10 to contact CA 
.320 (step 404). CX 200 additionally instructs CA 320 to issue a credential for user 310 
(step 406). 

1 5 Next, user 3 1 0 (or a browser for user 310) constructs a public key/private key pair 

(step 408), and then sends the newly created public key along with a request for a 
credential to CA 320 (step 410). 

CA 320 then verifies the authenticity of the request (step 412). This process 
involves determining if CX 200 has instructed CA 320 to issue the credential 330, It also 

20 involves performing some type of manual or automated identity check on user 310. For 
example, the check can involve a database lookup of information on user 3 10, an 
interview with user 3 10, a telephone call to user 3 10 or a facsimile communication with 
user 310. 

If the request is properly verified, CA 320 signs credential 330 with a private key 
25 belonging to CA 320 (step 414), and returns credential 330 to user 3 10 and to CX 200 
(step 416). CX 200 then places the new credential 330 for user 310 in its database 301 
. (step 418). Note that credential 330 is signed by CA 320 and includes a public key for 
user 310. 
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Also note that it is desirable to make CX 200 and CA 320 independent of each 
other. This makes perpetrating a fraud during the trading and/or settlement processes 
harder, because such fraud requires collusion between CX 200 and CA 320. 



5 Process of Obtaining Authority to Grant Permissions 

FIG. 5 is a flow chart illustrating how a security officer 3 12 obtains authority to 
grant permissions in accordance with an embodiment of the present invention. The 
process starts when an officer of a member organization of exchange 200, such as the 
CEO of organization 302, executes an exchange agreement with exchange 200 (step 502). 

10 This exchange agreement includes a schedule identifying security officers within 
organization 302 who are to be granted authority to confer permissions upon users 
belonging to organization 302. 

Next, security officer 312 within organization 302 obtains a credential 33 1 from 
CA 320 through the process outlined in FIG. 4 above (step 504). Security officer 312 

1 5 then communicates credential 33 1 to security officer 314, who belongs to exchange 
organization 306. Next, security officer 3 14 checks the identity of security officer 312 
through telephone calls, facsimile communications or other means. 

If the identity or security officer 312 is confirmed to be one of the listed security 
officers in the schedule of step 502, security officer 314 enables the security officer 

20 permission in the permissions table of the database by signing the database record 33 1 
through the process described below in Figure 6 with a private key belonging to security 
officer 314. At this point, security officer 312 is authorized by both CA 320 and security 
officer 314. 

Security officer 314 then stores the signed permission record 331 in database 301 
25 within exchange organization 306 (step 506). Security officer 314 also returns the signed 
credential 331 to security officer 312 (step 508). 
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Process of Obtaining a Permission 

FIG. 6 is a flow chart illustrating the process of obtaining a permission 340 from a 
security officer 3 1 2 for a user 3 1 0 in accordance with an embodiment of the present 
invention. User 310 first sends a request to security officer 3 12 to obtain a permission, 
5 such as the permission to trade (step 602). Note that this request includes credential 330 
for user 310. 

Security officer 312 then validates the identity of user 310 by examining 
credential 330 (step 604). If the identity validates, security officer 3 12 determines 
whether to grant the permission based upon a rule or some other process defined by 

1 0 organization 3 02 (step 606) . 

If the permission is to be granted, security officer 312 signs the request with a 
private key belonging to security officer 312, and then stores the request within 
permission table 305 (step 608). Security officer 312 then sends an acknowledgement to 
user 310 to complete the process (step 610). 

15 If the permission is not to be granted, security officer 312 sends a request denial 

to user 310 (step 612). 

Note that permission table 305 contains a row (entry) for each user. This row 
contains a number of separately signed fields indicating various permissions. For 
example, a given entry for user 310 may include a unique string identifying a permission 

20 (for example, the name of the permission), as well as the public key of user 310, all of 
which is signed with the private key of security officer 312. 

Process of Facilitating a Trade 

FIG. 7 is a flow chart illustrating the process of facilitating a trade in accordance 
25 with an embodiment of the present invention. This process starts when a user 3 1 0 creates 
and digitally signs a quote request, and sends the quote request to CX 200 (step 702). 
Note that this quote request can include a list of banks to engage. 
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Also note that the term "digitally signing" refers to the process of signing a 
message with a private key belonging to a first entity so that other entities can use a 
public key belonging to the first entity to verify that the message was signed with the 
private key belonging to the first entity. 
5 Upon receiving the quote request, CX 200 looks up the trading permission for 

user 3 10 in permission table 305. If the entry in permission table 305 is null (empty), CX 
200 rejects the quote request. Otherwise, CX 200 appends the permission for user 3 10 to 
a trade record containing the quote request (step 704). CX 200 then broadcasts the trade 
record to the specified bank users (step 706). 
1 0 Each bank user 3 1 8 who receives the trade record checks the signature on the 

quote request to validate the identity of user 3 10, and also checks permission information 
in the trade record to verify that user 3 1 0 has permission to perform the trade (step 708). 

If the identity and permission are valid, each interested bank user 3 1 8 adds a price 
quote to the trade record, signs the trade record, and returns the trade record to CX 200 
15 (step 710). 

Next, CX 200 receives trade records with quotes from interested bank users (step 
712). CX 200 then performs checks on the quotes and retrieves trading permissions for 
each interested bank user from permission table 305. If these trading permissions are not 
null, CX 200 appends the permissions to the trade record (step 714). 

20 When all quotes have been received and the auction time expires, CX 200 returns 

the augmented trade record to user 310 (step 716). Note that although the present 
example is presented in the context of a reverse competitive auction, the present 
invention can generally be applied to trading and settling systems that use any type of 
pricing mechanism, and is not limited to reverse competitive auctions. 

25 Next, user 3 1 0 examines all of the quotes in the trade record, and selects one for 

execution. If a quote is selected, user 310 tests the signature and permissions of the 
quote. If these are valid, user 310 signs the portion of the trade record with the selected 
quote, and returns the trade record to CX 200 (step 718). 
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Upon receiving the trade record, CX 200 tests the time of receipt. If no bank user 
has sent a cancellation prior to receipt of the user selection, and if the decision time has 
not expired for user 3 10, CX 200 records the trade in database 301. Upon successful 
commit, CX 200 sends the appropriate subset of the trade to the winning bank user, and 
5 informs all other bank users and user 3 10 of success or failure (step 720). 

Next, bank user 310 sends the trade record to settlement clerk 3 1 1 within the ' 
same organization 302 to settle the trade (step 722). 

Process of Settling a Trade 

10 FIG. 8 is a flow chart illustrating the process of settling a trade in accordance with 

an embodiment of the present invention. The process starts when settlement clerk 311 
augments the trade record with allocations of funds and physical settlement instructions. 
Settlement clerk 311 then signs the related fields of the trade record and forwards the 
trade record to CX 200 (step 802). Note that if the settlement instructions are default 

1 5 (standing) instructions, settlement clerk 3 1 1 may not have to append additional settlement 
instructions to the trade record. Settlement clerk 3 1 1 also sends payment instructions to 
funds transfer agent 220. 

Upon receiving the trade record, CX 200 looks up the settlement permission for 
settlement clerk 3 1 L If this permission is not null, CX 200 adds the permission to the 

20 trade record (step 804). CX 200 then commits the trade record to database 301 (step 
806), and sends the trade record to bank settlement clerk 319 (step 808). 

Upon receiving the trade record, bank settlement clerk 319 checks the signature 
and settlement permission of settlement clerk 311, and possibly checks other signatures 
and permissions in the trade record. If all are valid, settlement clerk 3 1 9 sends 

25 instructions to funds transfer agent 22 1 to complete the trade (step 810). 
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Trade Record Structure 

FIG. 9 illustrates the structure portions of a trade record 900 in accordance with 
an embodiment of the present invention to trade Spot Foreign Currency Exchange (FX). 
Trade record 900 includes a number of fields, some of which are illustrated in FIG. 9. 
5 These fields include trade date 902, which identifies the date the trade took place, and 
value date 904 which identifies the date the currency is to be exchanged. 

Currency 1 (CCY1) identifier 906 identifies a first currency involved in the trade 
(such as US Dollars). CCY1. amount 908 specifies an amount of the first currency 
involved in the trade. CCY2 identifier 910 identifies a second currency involved in the 
10 trade (such as Japanese Yen). CCY2 amount 912 specifies an amount of the second 

currency involved in the trade. Conversion rate 914 specifies a conversion rate between 
the first currency and the second currency. 

CCY1 organizational 6 identifies a first organization involved in the trade, and 
CCY1 subsidiary 918 identifies a specific subsidiary of the first organization that is 
1 5 involved in the trade. CCY2 organization 920 identifies a second organization involved 
in the trade, and CC Y2 subsidiary 922 identifies a specific subsidiary of the second 
organization that is involved in the trade. 

CCY1 account 924 identifies and account for the first organization, and CCY1 
custodian 926 identifies an institution (bank) maintaining the account for the first 
20 organization. CCY2 account 928 identifies and account for the second organization, and 
CCY2 custodian 930 identifies an institution maintaining the account for the second 
organization. 

There are also trading and settlement signatures for currency one, 932 and 934, as 
well as trading and settlement signatures for currency two, 936 and 938. 
25 Note that certain portions of trade record 900 are signed by a user, such as front 

office trader 310, and other portions are signed by a settlement clerk, such as settlement 
clerk 311. In particular, front office trader 310 signs portions of trade record 900 that 
include trade parameters. Settlement clerk 3 1 1 signs these as well as the portions of trade 
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record 900 that contain settlement instructions, such as account identifiers. (The "1" 
values in FIG. 9 indicate which portions of the trade record are signed by respective 
entities, and the "S" values indicate the respective digital signatures.) 

The foregoing descriptions of embodiments of the invention have been presented 
5 for purposes of illustration and description only. They are not intended to be exhaustive 
or to limit the present invention to the forms disclosed. Accordingly, many modifications 
and variations will be apparent to practitioners skilled in the art. Additionally, the above 
disclosure is not intended to limit the present invention. The scope of the present 
invention is defined by the appended claims. 

10 
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What Is Claimed Is: 

1 . A method for using digital signatures in performing validations to 
facilitate a trade, comprising: 

5 receiving a quote related to the trade at a first computer system; 

wherein the quote includes permission information that facilitates determining 
permissions that have been granted to a quote maker who is making the quote; 

validating that the quote maker digitally signed the quote by using a public key of 
the quote maker to verify that the quote was signed by a corresponding private key 
1 0 belonging to the quote maker; 

validating that the quote maker has permission to perform the trade by using a 
public key of a first security officer to verify that the permission information was signed 
by a corresponding private key belonging to the first security officer, thereby authorizing 
the quote maker to perform the trade; 
15 if the quote is to be accepted, accepting the quote by, 

signing the quote with a private key belonging to a quote receiver, 

and 

communicating a trade record including the signed quote to the 
quote maker. 

20 

2. The method of claim 1, further comprising validating the identity of the 
quote maker by using a public key of a certification authority to verify that a certificate 
containing the public key of the quote maker was signed by a corresponding private key 
belonging to the certification authority, 

25 wherein the signing by the certification authority indicates that the certification 

authority has verified the identity of the quote maker. 
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3. The method of claim 2, wherein the quote includes multiple quotes from 
multiple quote makers, and wherein the multiple quotes have been aggregated by a trade 
facilitator. 

5 4. The method of claim 3, wherein communicating the trade record to the 

quote maker involves : 

sending the trade record to the trade facilitator; and 

allowing the trade facilitator to send the trade record to the quote maker. 

10 5. The method of claim 1 , further comprising; 

prior to receiving the quote at the first computer system, communicating a quote 
request from the quote receiver on the first computer system to the quote maker; 
allowing the quote maker to validate the identity of the quote receiver; 
allowing the quote maker to validate that the quote receiver has permission to 
1 5 perform the trade by using a public key of a second security officer associated with the 
quote receiver to verify that permission information within the quote request was signed 
by a corresponding private key belonging to the second security officer, thereby 
authorizing the quote receiver to perform the trade. 

20 6. The method of claim 1 , wherein accepting the quote further comprises 

sending the trade record to a settlement clerk associated with the quote receiver who is 
responsible for settling the trade. 

7. The method of claim 1, wherein prior to receiving the quote the method 
25 further comprises, allowing the quote maker to obtain permission to make the trade by: 
sending a request for permission to the first security officer associated with the 
quote maker; 
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allowing the first security officer to digitally sign a permission record to indicate 
the quote maker has permission to trade. 

8. The method of claim 1, wherein the trade involves foreign exchange and 
5 wherein the trade record includes: 

a trade date; 

an identifier for a first currency; 
a first currency amount; 

an identifier for a first organization providing the first currency; 
10 an identifier for a second currency; 

a second currency amount; and 

an identifier for a second organization providing the second currency. 

9. A method for using digital signatures in performing validations to 
facilitate a trade, comprising: 

receiving a trade record from a quote receiver who has accepted a quote and has 
thereby created the trade; 

wherein the trade record is received by a first settlement clerk associated with the 
quote receiver, who is responsible for settling the trade; 

augmenting the trade record with settlement instructions identifying at least one 
account to be used in settling the trade; 

signing the trade record with a private key belonging to the first settlement clerk; 
communicating the trade record to a second settlement clerk associated with a 
quote maker. 

10. The method of claim 9, further comprising: 
receiving the trade record at the second settlement clerk; 
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using a public key belonging to the first settlement clerk to validate that the first 
settlement clerk has signed to trade record; 

validating that the first settlement clerk has been granted permission to settle the 
trade by examining permission information contained within the trade record to verify 
5 that a first security officer associated with the first settlement clerk has digitally signed 
the permission information in order to authorize the first settlement clerk to settle the 
trade; and 

communicating the trade to a funds transfer agent to carry out the trade. 

10 1 1 • The method of claim 1 0, wherein communicating the trade record to the 

second settlement clerk involves: 

sending the trade record to a trade facilitator; 

allowing the trade facilitator to augment the trade record with the permission 
information for the first settlement clerk; and 
1 5 allowing the trade facilitator to forward the trade record to the second settlement 

clerk. 

12. The method of claim 9, wherein the trade involves foreign exchange and 
wherein the trade record includes: 
20 a trade date; 

an identifier for a first currency; 
a first currency amount; 

an identifier for a first organization providing the first currency; 
an identifier for a second currency; 
25 a second currency amount; and 

an identifier for a second organization providing the second currency. 



13. The method of claim 12, wherein the settlement instructions include: 
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an identifier for a first account belonging to the first organization; and 
an identifier for a second account belonging to the second organization. 

14. A method for using digital signatures in performing validations to 
5 facilitate a trade, comprising: 

receiving a quote request from a quote requester at a computer system belonging 
to a trade facilitator; 

looking up a trading permission for the quote requester from a database 
maintained by the trade facilitator; 
10 appending the trading permission to the quote request to form a trade record; 

communicating the trade record to potential quoting entities; 
receiving quotes from the potential quoting entities; 
augmenting the trade record to include the quotes; and 
sending the augmented trade record to the quote requester. 

15 

1 5 . The method of claim 1 4, further comprising: 
receiving a selection of a quote from the quote requester; and 

notifying each of the quoting entities about whether the quote they made was 
selected. 

20 

1 6. The method of claim 15, further comprising: 

receiving the trade record from a first settlement clerk associated with the quote 
requester; 

wherein the trade record includes settlement instructions appended to the trade 
25 record by the first settlement clerk; 

looking up permission information for the first settlement clerk in a database; 
augmenting the trade record with the permission information for the first 
settlement clerk; and 
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forwarding the trade record to a second settlement clerk associated with a quote 

maker; 

whereby the second settlement clerk can validate the permission information by 
verifying that the permission information was signed with a private key belonging to a 
5 first security officer associated with the first settlement clerk, thereby authorizing the first 
settlement clerk to settle the trade. 

17. The method of claim 16, wherein the trade involves foreign exchange and 
i the trade record includes: 
a trade date; 

an identifier for a first currency; 
a first currency amount; 

an identifier for a first organization providing the first currency; 
an identifier for a second currency; 
a second currency amount; and 

an identifier for a second organization providing the second currency. 

18. The method of claim 17, wherein the settlement instructions include: 
an identifier for a first account belonging to the first organization; and 
an identifier for a second account belonging to the second organization. 

19. A computer-readable storage medium storing instructions that when 
executed by a computer cause the computer to perform a method for using digital 
signatures in performing validations to facilitate a trade, the method comprising: 

25 receiving a quote related to the trade at a first computer system; 

wherein the quote includes permission information that facilitates determining 
permissions that have been granted to a quote maker who is making the quote; 
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validating that the quote maker digitally signed the quote by using a public key of 
the quote maker to verify that the quote was signed by a corresponding private key 
belonging to the quote maker; 

validating that the quote maker has permission to perform the trade by using a 
5 public key of a first security officer to verify that the permission information was signed 
by a corresponding private key belonging to the first security officer, thereby authorizing 
. the quote maker to perform the trade; 

if the quote is to be accepted, accepting the quote by, 

signing the quote with a private key belonging to a quote receiver, 

10 and 

communicating a trade record including the signed quote to the 
quote maker. 

20. The computer-readable storage medium of claim 19, wherein the method 
further comprises validating the identity of the quote maker by using a public key of a 
certification authority to verify that a certificate containing the public key of the quote 
maker was signed by a corresponding private key belonging to the certification authority, 

wherein the signing by the certification authority indicates that the certification 
authority has verified the identity of the quote maker. 

2 1 . The computer-readable storage medium of claim 20, wherein the quote 
includes multiple quotes from multiple quote makers, and wherein the multiple quotes 
have been aggregated by a trade facilitator. 

22. The computer-readable storage medium of claim 2 1 , wherein 
communicating the trade record to the quote maker involves: 

sending the trade record to the trade facilitator; and 
allowing the trade facilitator to send the trade record to the quote maker. 
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23 . The computer-readable storage medium of claim 1 9, wherein the method 
further comprises: 

prior to receiving the quote at the first computer system, communicating a quote 
5 request from the quote receiver on the first computer system to the quote maker; 
allowing the quote maker to validate the identity of the quote receiver; 
allowing the quote maker to validate that the quote receiver has permission to 
perform the trade by using a public key of a second security officer associated with the 
quote receiver to verify that permission information within the quote request was signed 
10 by a corresponding private key belonging to the second security officer, thereby 
authorizing the quote receiver to perform the trade. 

24. The computer-readable storage medium of claim 19, wherein accepting 
the quote further comprises sending the trade record to a settlement clerk associated with 

15 the quote receiver who is responsible for settling the trade. 

25. The computer-readable storage medium of claim 19, wherein prior to 
receiving the quote, the method further comprises allowing the quote maker to obtain 
permission to make the trade by: 

20 sending a request for permission to the first security officer associated with the 

quote maker; 

allowing the first security officer to digitally sign a permission recprd to indicate 
the quote maker has permission to trade. 

25 26. The computer-readable storage medium of claim 1 9, wherein the trade 

involves foreign exchange and wherein the trade record includes: 
a trade date; 

an identifier for a first currency; 
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a first currency amount; 

an identifier for a first organization providing the first currency; 
an identifier for a second currency; 
a second currency amount; and 
5 an identifier for a second organization providing the second currency. 

27. A computer-readable storage medium storing instructions that when 
executed by a computer cause the computer to perform a method for using digital 
signatures in performing validations to facilitate a trade, the method comprising: 
10 receiving a trade record from a quote receiver who has accepted a quote and has 

thereby created the trade; 

wherein the trade record is received by a first settlement clerk associated with the 
quote receiver, who is responsible for settling the trade; 

augmenting the trade record with settlement instructions identifying at least one 
1 5 account to be used in settling the trade; 

signing the trade record with a private key belonging to the first settlement clerk; 

communicating the trade record to a second settlement clerk associated with a 
quote maker. 

20 28. The computer-readable storage medium of claim 27, wherein the method 

further comprises: 

receiving the trade record at the second settlement clerk; 
using a public key belonging to the first settlement clerk to validate that the first 
settlement clerk has signed to trade record; 
25 validating that the first settlement clerk has been granted permission to settle the 

trade by examining permission information contained within the trade record to verify 
that a first security officer associated with the first settlement clerk has digitally signed 
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the permission information in order to authorize the first settlement clerk to settle the 
trade; and 

communicating the trade to a funds transfer agent to carry out the trade. 

5 29 . The computer-readable storage medium of claim 27, wherein 

communicating the trade record to the second settlement clerk involves: 
sending the trade record to a trade facilitator; 

allowing the trade facilitator to augment the trade record with the permission 
information for the first settlement clerk; and 
1 0 allowing the trade facilitator to forward the trade record to the second settlement 

clerk. 



30. The computer-readable storage medium of claim 27, wherein the trade 
involves foreign exchange and wherein the trade record includes: 

15 a trade date; 

an identifier for a first currency; 
a first currency amount; 

an identifier for a first organization providing the first currency; 
an identifier for a second currency; 
20 a second currency amount; and 

an identifier for a second organization providing the second currency. 

3 1 . The computer-readable storage medium of claim 30, wherein the 
settlement instructions include: 

25 an identifier for a first account belonging to the first organization; and 

an identifier for a second account belonging to the second organization. 



WO 02/39401 



PCT/US01/31643 



28 

32. A computer-readable storage medium storing instructions that when 
executed by a computer cause the computer to perform a method for using digital 
signatures in performing validations to facilitate a trade, the method comprising: 

receiving a quote request from a quote requester at a computer system belonging 
5 to a trade facilitator; 

looking up a trading permission for the quote requester from a database 
maintained by the trade facilitator; 

appending the trading permission to the quote request to form a trade record; 
communicating the trade record to potential quoting entities; 
10 receiving quotes from the potential quoting entities; 

augmenting the trade record to include the quotes; and 
sending the augmented trade record to the quote requester. 

33. The computer-readable storage medium of claim 32, wherein the method 
1 5 further comprises: 

receiving a selection of a quote from the quote requester; and 
notifying each of the quoting entities about whether the quote they made was 
selected. 



20 34. The computer-readable storage medium of claim 33, wherein the method 

further comprises: 

receiving the trade record from a first settlement clerk associated with the quote 
requester; 

wherein the trade record includes settlement instructions appended to the trade 
25 record by the first settlement clerk; 

looking up permission information for the first settlement clerk in a database; 
augmenting the trade record with the permission information for the first 
settlement clerk; and 
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forwarding the trade record to a second settlement clerk associated with a quote 

maker; 

whereby the second settlement clerk can validate the permission information by 
verifying that the permission information was signed with a private key belonging to a 
5 first security officer associated with the first settlement clerk, thereby authorizing the first 
settlement clerk to settle the trade. 



35. The computer-readable storage medium of claim 34, wherein the trade 
involves foreign exchange and wherein the trade record includes: 

10 a trade date; 

an identifier for a first currency; 
a first currency amount; 

an identifier for a first organization providing the first currency; 
an identifier for a second currency; 
1 5 a second currency amount; and 

an identifier for a second organization providing the second currency. 

36. The computer-readable storage medium of claim 35, wherein the 
settlement instructions include: 

20 an identifier for a first account belonging to the first organization; and 

an identifier for a second account belonging to the second organization. 

37. An apparatus that uses digital signatures in performing validations to 
facilitate a trade, comprising: 

25 a receiving mechanism that is configured to receive a quote related to the trade at 

a first computer system; 

wherein the quote includes permission information that facilitates determining 
permissions that have been granted to a quote maker who is making the quote; 
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a validation mechanism that is configured to validate that the quote maker 
digitally signed the quote by using a public key of the quote maker to verify that the 
quote was signed by a corresponding private key belonging to the quote maker; 

wherein the validation mechanism is further configured to validate that the quote 
5 maker has permission to perform the trade by using a public key of a first security officer 
to verify that the permission information was signed by a corresponding private key 
belonging to the first security officer, thereby authorizing the quote maker to perform the 
trade; 

a quote accepting mechanism, wherein if the quote is to be accepted, the quote 
1 0 accepting mechanism is configured to, 

sign the quote with a private key belonging to a quote receiver, and 

to 

communicate a trade record including the signed quote to the quote 

maker. 

15 

38. The apparatus of claim 37, wherein the validation mechanism is further 
configured to validate the identity of the quote maker by using a public key of a 
certification authority to verify that a certificate containing the public key of the quote 
maker was signed by a corresponding private key belonging to the certification authority, 
20 wherein the signing by the certification authority indicates that the certification 

authority has verified the identity of the quote maker. 



39. The apparatus of claim 38, wherein the quote includes multiple quotes 
from multiple quote makers, and wherein the multiple quotes have been aggregated by a 

25 trade facilitator. 

40. The apparatus of claim 39, wherein in communicating the trade record to 
the quote maker, the quote accepting mechanism is configured to: 
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send the trade record to the trade facilitator so that the trade facilitator can send 
the trade record to the quote maker. 

41 . The apparatus of claim 37, further comprising a quote requesting 
5 mechanism that is configured to: 

communicate a quote request from the quote receiver on the first computer system 
to the quote maker, so that the quote maker can validate the identity of the quote receiver, 
and so that the quote maker can validate that the quote receiver has permission to perform 
the trade by using a public key of a second security officer associated with the quote 
10 receiver to verify that permission information within the quote request was sighed by a 
corresponding private key belonging to the second security officer, thereby authorizing 
the quote receiver to perform the trade. 



42, The apparatus of claim 37, wherein the quote accepting mechanism is 
1 5 further configured to send the trade record to a settlement clerk associated with the quote 
receiver who is responsible for settling the trade. 



43. The apparatus of claim 37, further comprising a permission mechanism 
that is configured to obtain permission for the quote maker to make the trade by: 
20 sending a request for permission to the first security officer associated with the 

quote maker; 

allowing the first security officer to digitally sign a permission record to indicate 
the quote maker has permission to trade. 

25 44. The apparatus of claim 39, wherein the trade involves foreign exchange 

and wherein the trade record includes: 
a trade date; 

an identifier for a first currency; 
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an identifier for a first organization providing the first currency; 
an identifier for a second currency; 
a second currency amount; and 
5 an identifier for a second organization providing the second currency. 

45. An apparatus that uses digital signatures in performing validations to 
facilitate a trade, comprising: 

a first receiving mechanism that is configured to receive a trade record from a 
10 quote receiver who has accepted a quote and has thereby created the trade; 

wherein the trade record is received by a first settlement clerk associated with the 
quote receiver, who is responsible for settling the trade; 

a settlement instruction mechanism that is configured to augment the trade record 
with settlement instructions identifying at least one account to be used in settling the 
15 trade; 

a signing mechanism that is configured to sign the trade record with a private key 
belonging to the first settlement clerk; 

a first communication mechanism that is configured to communicate the trade 
record to a second settlement clerk associated with a quote maker. 

20 

46, The apparatus of claim 45, further comprising; 

a second receiving mechanism that is configured to receive the trade record for 
the second settlement clerk; 

a validation mechanism for the second settlement clerk that is configured to use a 
25 public key belonging to the first settlement clerk to validate that the first settlement clerk 
has signed to trade record; 

wherein the validation mechanism is additionally configured to validate that the 
first settlement clerk has been granted permission to settle the trade by examining 
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permission information contained within the trade record to verify that a first security 
officer associated with the first settlement clerk has digitally signed the permission 
information in order to authorize the first settlement clerk to settle the trade; and 
a second communication mechanism for the second settlement clerk that is 
5 configured to communicate the trade to a funds transfer agent to carry out the trade. 

47. The apparatus of claim 46, wherein the first communication mechanism is 
configured to send the trade record to a trade facilitator, so that the trade facilitator can 
augment the trade record with the permission information for the first settlement clerk 

10 before forwarding the trade record to the second settlement clerk. 

48. The apparatus of claim 47, wherein the trade involves foreign exchange 
and wherein the trade record includes: 

a trade date; 
1 5 an identifier for a first currency; 

a first currency amount; 

an identifier for a first organization providing the first currency; 
an identifier for a second currency; 
a second currency amount; and 
20 an identifier for a second organization providing the second currency. 

49. The apparatus of claim 48, wherein the settlement instructions include: 
an identifier for a first account belonging to the first organization; and 

an identifier for a second account belonging to the second organization. 

25 

50. An apparatus that uses digital signatures in performing validations to 
facilitate a trade, comprising: 
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a receiving mechanism, within a computer system belonging to a trade facilitator, 
that is configured to receive a quote request from a quote requester; 

a lookup mechanism that is configured to look up a trading permission for the 
quote requester from a database maintained by the trade facilitator; 
5 an appending mechanism that is configured to append the trading permission to 

the quote request to form a trade record; 

a communication mechanism that is configured to communicate the trade record 
to potential quoting entities; 

wherein the receiving mechanism is additionally configured to receive quotes 
1 0 from the potential quoting entities; 

an augmenting mechanism that is configured to augment the trade record to 
include the quotes; and 

a sending mechanism that is configured to send the augmented trade record to the 
quote requester. 

15 

5 1 . The apparatus of claim 50, wherein the receiving mechanism is 
additionally configured to receive a selection of a quote from the quote requester, and 
further comprising a notification mechanism that is configured to notify each of the 
quoting entities about whether the quote they made was selected. 

20 

52 . The apparatus of claim 5 1 , 

wherein the receiving mechanism is additionally configured to receive the trade 
record from a first settlement clerk associated with the quote requester; 

. wherein the trade record includes settlement instructions appended to the trade 
25 record by the first settlement clerk; 

wherein the lookup mechanism is additionally configured to look up permission 
information for the first settlement clerk in a database; 
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wherein the augmenting mechanism is additionally configured to augment the 
trade record with the permission information for the first settlement clerk; and 

wherein the sending mechanism is additionally configured to forward the trade 
record to a second settlement clerk associated with a quote maker; 
5 whereby the second settlement clerk can validate the permission information by 

verifying that the permission information was signed with a private key belonging to a 
first security officer associated with the first settlement clerk, thereby authorizing the first 
settlement clerk to settle the trade, 

10 53 . The apparatus of claim 52, wherein the trade involves foreign exchange 

and wherein the trade record includes: 
a trade date; 

an identifier for a first currency; 
a first currency amount; 
1 5 an identifier for a first organization providing the first currency; 

an identifier for a second currency; 
a second currency amount; and 

an identifier for a second organization providing the second currency. 

20 54. The apparatus of claim 53, wherein the settlement instructions include: 

an identifier for a first account belonging to the first organization; and 
an identifier for a second account belonging to the second organization. 
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